Intention and Design «
»


Code: , , , , , , ,
1 comment

The recently-sorta-released MMORPG Darkfall is having trouble with players macroing (running programs that play their characters to build up characters and resources without a player’s attention).

Macroing: We are working to address it at its source, but until then we need to enforce our policies. Before we do that we will appeal to players not actually playing the game to log off rather than leaving their character in-game. This will allow more people to be able to enjoy Darkfall instead of unmanned characters taking up server space. If you’re skilling up by not playing the game as it was intended, you will be kicked and repeated offenses will result in a ban.

That last sentence really caught my attention because I’ve been thinking a lot about the process of learning to program. One of the most frustrating things new programmers have to learn is that it doesn’t matter what you want the computer to do, it matters what you tell the computer to do. The difference between the two is called “bugs”.

A computer game’s design shouldn’t be broken if the players have perfect aim, perfect recall, infinite patience for repetitive tasks, instant 24/7 availability, because those are all things they’ll get by using their computer fully. You can try to punish it (as Darkfall is doing), try to detect it (as World of Warcraft and CounterStrike do), try to build a community to police it (as LAN parties do), or try to ignore it (as most small multiplayer games do), but your design will be broken. (Adopting these constraints in the design of a tabletop game hurts as often as it aids, interestingly.)

This is fundamental to creating programs, games, markets, markets, rules, taxes, laws: the system works as you designed it, not as you intended it.

Careful testing can expose the gaps between intention and design, and this is where I find theoretical knowledge becomes practical. The more I read about state machines, parsing, multiplayer mechanics, networking, level design, feedback loops, sociology, database schemas, and a dozen other topics, the better I can predict and the faster I can recognize these problems.


Comments

Leave a Reply

Your email address will not be published.