Double Buffered

A Programmer’s View of Game Design, Development, and Culture

Archive for August, 2009

Coding on the Edge: How To Survive

Posted by Ben Zeigler on August 18, 2009

In the theoretical “well run company” there will never be a situation where you, the programmer, will have to write incredibly critical code under extreme time pressure. These companies are either extremely boring or quickly go out of business. In today’s exciting world of Online Game Development, this is inevitable and is known as “launch”. Now, not everyone will have to engage in this practice¬† but anyone working on infrastructure or performance will find themselves suddenly under heavy demand a few weeks before any big update. I suggest running away. If you’re better at programming then you are at running away (I’m very bad at running away) here’s some advice that may help you out when you have to write 5,000 lines of mission critical code in 2 days:

  1. Channel the Rage: The reason you have to work 70 hours this week is inevitably because someone screwed up. It could be you, a coworker, or a third party, but the cause is going to be a mix of forseeable and unforseeable mistakes. Feel free to note your theories on the personal failings that brought you here, but until things are actually working there’s really no point in complaining to anyone about it. There is no way to keep track of all the possible issues involved with an online game, so missing something critical just means you are human. Whatever anger you feel about the cause of the situation, you want to focus it towards the code itself and not who wrote it. Anger is a pretty good short-term motivator
  2. Focus Your Efforts: Programmers already have a hard time dealing with distractions and interruptions, but during a crisis this gets even harder. When there are 5 critical things going wrong at once, the natural inclination is to try and work on all 5 at once. However, this just means you’ll fail to fix 5 critical issues. Try to pick a problem that you think matches well with your skill set and coordinate with other programmers to get the rest managed or delayed. Departmental divisions and work politics should be basically discarded at this point, because no (sane) person will complain about your rudeness while the world is on fire.
  3. Enforce Breaks: When you have a lot of work to be done in a short period of time, you need to be careful to give your brain some time to relax. The relaxation time between hard crunching is often when you realize the insight that can save you 6 hours of horrible manual debugging. I like to code/debug for 3 hours or so at a time during crunch, and it’s hard to beat video games for breaktime. Also, you NEED to get at least some sleep. Never work on less than 6 hours of sleep, the amount of bugs you add when tired will cost you far more time then you gain by skipping sleep
  4. Assume You Are Stupid: I generally like to design for ease of debugging, but this is absolutely critical during crisis.¬† When you write code under pressure the odds of you making a mistake are higher, and your code should be structured with this in mind. Whenever you add in a new feature make it run-time switchable at the expense of code simplicity. Add in all the logging you can think of. All forms of cleverness should be strictly banned. I’m not normally into code review or pair programming, but when you’re tired you NEED someone else’s eyes on your code. One of you will figure out the part you screwed up.

Finally, there has to be a point where the crisis Ends. If a company tries to make you crunch for more than a month at a time, you’re at a company that doesn’t either doesn’t understand how programmers work, or is completely incompetent at scheduling. It can definitely be exciting and rewarding to put in long hours and accomplish the impossible, but you WILL burn out. But, hey, I guess some people like the burning out part?

Posted in Game Development | Tagged: , , , | 1 Comment »

The Irrationality of Pricing

Posted by Ben Zeigler on August 5, 2009

Digital distribution has brought many massive improvements to the world of gaming. It’s generally made things easier to buy and opened up exciting new business opportunities. However, it has brought with it one giant item of confusion: Pricing. Up until about 4 or 5 years ago pricing of games was generally pretty simple and uniform ($50 +- $10 depending on platform, or $20 if your game was explicitly budget-priced). It was this way because of the combination of distribution cost and inertia. In contrast, pricing and perceived value in today’s world is all over the place. You get weirdness like Trine PC being $10 more than Trine for PS3, despite the fact that the PC version doesn’t require a royalty payment to Sony. Peggle is $5 on the iPhone, $10 on Steam, and $20 on Popcap’s own site, despite being an identical game and all being digital. And I haven’t even gotten to DLC yet, where the pricing is so random and the users so confused that it leads to random accusations of developer cheating when blogs misunderstand the small size of executable code. The platform owners, the publishers, the developers, the press, and the users all claim they know the RIGHT way to price and value gaming content in today’s world, but they’re all wrong. There are at least 4 completely distinct ways of pricing and valuing games, and they’re mostly incompatible.

One value model is based on cost of production. The theory here is that the more expensive something is to produce, the more you should charge for it. It makes intuitive sense to developers and publishers, but the gaming public has no concept of how expensive games are to produce and will be upset when their guesses about relative development costs are wrong. The user-preferred equivalent to tieing it to development cost is tieing it to hours of gameplay. Many players (especially the younger set with more time then money) value playing time strongly, which is where that nebulous and always incorrect “replay value” number comes from in reviews. The negative effect of this value model is that it tends to lead to games that are artificially lengthened and have shitty superflous multiplayer modes. A third model is to price and value games relative to similar and successful already released games. This works well for clones within existing genres and on established platforms (ie, this is why everythins is $50), but is no help for new genres or platforms. This means that it’s even harder to get new genres and platforms approved for publishing. The last model is to make a pricing decision purely based on achieving maximum total profit, which is possible because the physical cost is very low. Assuming a neglible distribution cost (ie, old PC games on Steam) selling 100,000 copies of a game at $5 is better than selling 40,000 copies at $10, but not as good as selling 30,000 copies at $20. The problem with this approach is that the empirical data for this is really lacking (Valve desperately needs to release comprehensive sales numbers for steam games), pricing for the maximal short term profit can lead to customers feeling ripped off and lower your profits on future releases.

So what happens when these pricing models interact? Developers and platform holders always trot out “increased development costs” to explain the rise in game prices, but this model makes the least sense out of the 4. Frankly, development costs have no useful relationship to final game quality, given the long history of high-cost flops in our industry. Why should the end user care at all about how hard the game was to make? Every time someone in the industry tries to use production costs to justify price it just irritates users. Never say this. Beyond that one, the other 3 models are all fairly reasonable. Given theoretical economics the pure-profit model is always the best, but that ignores the significant psychological drawbacks to it. Ask Hellgate London if player anger over perceived pricing disparity can be a problem for a game. It’s a great model for pricing re-releases of old games, though. Basically, you want to balance economic optimization against player expectations. Players go in with expectations of pricing relative to other games (and some relative to other time-taking entertainment activities), and if you don’t meet those expectations players are going to be unhappy. If the price is too low some people won’t buy it out of suspicion, and if it’s too high players who can easily afford it won’t because they don’t want to feel ripped off. The worst part is, given the huge variation on value in today’s market no matter WHAT price you pick it will be compared to an existing product and will not meet the expectations of some percentage of players. Given today’s market, I think the best solution is probably to be as transparent as possible about your pricing, in an attempt to manage player expectations. Given that there are no unified standards for valuing games, you want to ease them into whatever pricing decision you do make.

Posted in Game Development | Tagged: , , , , , , | 2 Comments »