Programmer Joe

Flying Lab is looking to hire an operations lead and a PHP developer. Click the link for details!

Yesterday, Costik posted about the dark side of digital distribution. Pointing out that Xbox Live Arcade and Nintendo Virtual Console are the first steps toward a world where Game Stop and Wal-Mart lose most of their power in the game industry. Microsoft and Nintendo could use their new power in an all-download world to maintain tight control over the games that are available for their respective consoles. This is the world he fears might come:

If the manufacturers control distribution to their devices, they don’t have to be satisfied with $7. They can take basically whatever cut they like. Oh, they still have to ensure that publishers can make money, sometimes–but they can ensure that they themselves earn the lion’s share of whatever profits a title generates.

In other words, it’s possible that digital distribution, rather than freeing us from the problems of retail, will instead concentrate power even more heavily in the industry–concentrating it into the hands of the manufacturers. While this would be good for them, its a prospect that both developers and publishers should be scared about–and an outcome that could only serve to continue the field’s descent into mediocrity and imitation.

While this is a possibility it’s not the only one. Microsoft beat the crap out of Apple (and NeXT, Commodore, and countless other companies) by embracing the Windows development community. Microsoft makes the best development tools in the world, and gives a version of them away for free. If you don’t want to use their tools, they distribute the platform SDK for free and put all their API documentation on the web for anyone to use. They do the same thing for Windows CE and their other embedded operating systems.

Notably, Xbox development tools are absent from this list. Like all the other consoles, these are only available to registered developers who sign lengthy legal agreements and pony up big money for Dev kits. With XNA Studio they have opened up the Xbox 360 to developers who are willing to limited to C#. It also has no real mechanism for Xbox distribution short of distributing all your source code and assets to another member of the XNA Creators Club. They can then compile and run it locally.

These are obviously pretty severe restrictions, but I think the point the direction that Microsoft is headed with hobbyist 360 development. I expect them to announce a service that will enable XNA Creators Club members to share Xbox 360 executables with each other via XBLA within the year. By the end of 2008 I expect there to be a mechanism that allows club members to distribute games (and non-game Xbox applications) to non-members. Chances are that this system will let people sell their games on XBLA (with Microsoft taking a fairly hefty cut, of course.)

Microsoft isn’t doing all of this out of the goodness of their hearts, of course. They have decided that they want to own the living room, and the Xbox is their ticket into that market. However, unless they’ve forgotten the last 25 years of their own history, they aren’t going to shut out independent developers in the process. They rely on independent developers to develop everything between the small and ubiquitous utilities that they roll into the operating system and the massive application suites that they want to develop and market themselves. It’s these mid-sized products that really make the difference between Windows and MacOS as a platform, and it will be this same size of application that Microsoft can use to finish killing off Sony and start in on Nintendo.

That’s pretty good news if you can be one of those mid-sized products. And most games are firmly in that category.

When we started on Pirates we tried out two major pieces of procedural content and eventually ditched both of them. What appeared to us to be a panacea of free art was actually a rabbit hole of endless programmer resources. So while I love the idea of procedural content, I’m wary of including it at the core of a game. You have to evaluate your procedural content options very carefully.

We’re making a game that takes place largely on the water. Most of the time the screen is filled with sky and water.These were the two areas where we tried to use procedural content instead of something hand crafted. Neither of them worked out very well.
Procedural skies

Five years ago, or so, Naty Hoffman and Arcot J. Preetham had an article in Game Developer that was based on the work they did on environmental light scattering. The idea was that if you simulated the physical process of light moving through the atmosphere you could achieve the same sort of fantastic lighting conditions that you see in the real world. Read the paper if you want details, but the basic idea was that you could input certain atmospheric constants and the sky would paint itself.

The trouble was that these controls were extremely high level, and it was difficult to control them to get the results we wanted. With massive tweaking we could get results that looked ok in certain circumstances, but once you moved the sun or put in different terrain, it didn’t work so well anymore. And the skies always looked fairly bland because their approach didn’t include clouds, and we never figured out a way to add clouds to it that had the same kind of flexibility. Clouds are a whole other problem that people have tried to solve with procedural content all its own.

When we gave up on the raw formulas, we tried a few other approaches that let us control the lighting more directly with keyframes, but it didn’t really help. The artists still didn’t have as much control as they wanted and nobody was happy with the results.

So we ditched the whole thing and went to three very clear inputs. The artists understand them fully and produce amazing results:

• A hand-painted skydome texture – We start with panoramic shots of the actual sky, and then an artist removes jet contrails and beautifies them.
• The distance fog color at maximum distance – All the non-sky stuff fades to this color when if it gets far enough away. These are tuned to match the skydomes
• A scaling factor on the fog distance – Some environments don’t let you see as far because of “atmospheric haze”, but it’s really just distance fog. This is also matched to the skydomes.

Ocean Waves

We had a similar problem with the ocean waves. Most of the screen is covered with ocean most of the time, so we had to have a wave solution that could extend to the horizon. I can’t seem to find any of them now, but at the time (early 2003) there were several papers floating around that suggested using Fast Fourier Transforms (FFT) to simulate wave motion. We went ahead and implemented such a system that had about ten inputs with such helpful names as ‘a’ and ‘b’. Initially we tried to compute the FFTs at runtime, but even with a small grid it still took tons of CPU, so we started baking them offline and just playing back pre-animated wave sets.

This is another system that didn’t have any kind of reasonable artist control. Maybe they could have worked brilliantly given many more months of development, but we eventually ended up ditching them in favor of something much simpler. Now we’re using Perlin noise in viewspace to render the ocean waves, which is MUCH faster to compute and draw, and has controls that let us get the kind of results we’re looking for.

Make sure your procedural algorithms are ready

In both of these cases we picked algorithms that were not really ready to go into a game. There was no middleware for either one (though some ocean middleware has come on the scene since then), and were really just early academic research papers. These things are difficult to turn into amazing looking screenshots, and are probably just a waste of your time. Tried and true methods (like textured skydomes and distance fog) will get you reliable results in a reliable timeframe, and you would be well served to consider them seriously.

In the end, I’m very happy with the results. The game looks great, and I don’t miss the headaches that these two procedural approaches caused. Take a look at these screenshots and I think you’ll agree.

• Jungle beach
• Ships at sea
• Island jungle

I’m not saying that procedural content is bad. I think it shows great promise as a way out of ever-increasing budgets and spending millions of dollars of artist time on content that any given player is only going to see once. You just have to leave plenty of time to get your algorithms right, and build them with plenty of artist control.

Jason Booth and Danc at Lost Garden both posted on this recently. If you’re interested in procedural content, you should definately read both of their posts. There was also a recent article on Game Career Guide on the subject, but it was pretty light on actual meat.

The Austin Game Conference is now the Austin Game Developer’s Conference:

http://www.austingame.com/

It’s been reduced to four tracks:

• Online games
• Audio
• Game writing
• People’s Choice

I think I remember about twice that many tracks last year, but that doesn’t really mean much. They will probably run more than one session at a time in some tracks.

People’s Choice sounds interesting. I wonder if it will prevent the “you have to have been a speaker to be allowed to speak” catch-22 that GDC suffers from.

More comments on that Playdough report… My copy of Winning at New Products hasn’t arrived yet, though, so nothing specific about Stage-Gate.
While I agree that in an ideal world developers would be able to take multiple projects part of the way through development process and pick the best of them to survive at each phase, I’m not sure it’s practical. While the first few phases (like concept art and vision-level designs) are dirt cheap compared to the later phases (like cranking out thousands of models and a million lines of code), they aren’t free. Smaller companies (like the one I work for) may not even have the right personnel to develop multiple concepts at the same time.

Trying to keep track of this number of potential concepts is going to have a fair amount of overhead. In the case of an MMO, you have probably recently launched a game when you’re going through this process, and most of your team is still on the live team for the previous title. Running through exactly the same winnowing process, only in serial instead of parallel.

In this scenario, you would go through the same brainstorming session, but pick a much smaller number of ideas to develop into full blown game concepts. You might even concept out one at a time. You still run all the ideas and game concepts through exactly the same filters. You still need the same level of discipline to kill off weak ideas, you just don’t have to develop multiple concepts simultaneously.

In terms of actual dollars spent, the cost of these two methods is probably pretty similar. Assuming that your first concept doesn’t make it all the way through to release, you probably still build the same number of total concepts. You have to apply the tests the same number of times. The biggest difference in cost is the smaller overhead from trying to manage multiple concepts at once.

Of course the obvious disadvantage of serial concept development is that you don’t have multiple concepts going through the filters at the same time. When you can see all the concepts at the same time you can just rank them all from best to worst and, assuming they pass whatever requirements you have in your filter, let just the top few through to the next phase. When you are testing concepts one at a time days or weeks apart, you definitely aren’t going to be able to compare a given to the next one on the list, and you may not remember enough of the previous one to compare against THAT concept. You have to rely on absolute measurements of value, which are likely to be awfully subjective.

The best approach is probably to bite the bullet and develop many concepts in parallel in the early stages, and then cut back to a single project at the point where you dedicate significant staff to the project. The first phase is probably a single designer with a word processor spending a day on a few pages of design doc. The second phase is probably a week’s worth of expansion on that same design, a programmer spending a couple days taking a SWAG at what tech might be required (defining, not building), and a few days of a concept artist’s time to come up with some initial visuals. Not a big price to pay to be able to pick the cream of the crop.

How did the last game concept selection process you went through go? Were competing game ideas allowed to progress beyond the one-page-description level, or did you pretty much pick the next game idea in the initial brainstorming and run with it?