Prior to Adventure World, I spent a few weeks on my own developing a version of Connect 4 using html5, javascript, python, google app engine, and facebook. I dubbed it Connected 4 - the idea being that the player is settling a debt to "connected" mobsters by playing the game. It included both single player with AI and async multiplayer with your facebook friends. As a game, it was a failure. Single player quickly got boring and there wasn't enough depth or choice in a multiplayer turn. However, I learned a lot about technologies and languages that were new to me and shipped a game on my own, which were my main goals for the project. Overall it was a personal success.
In the year ahead I'm looking forward to even more programming, writing, and most importantly, shipping!
Over the weekend I wrote a simple pixel shader using Inigo Quilez's Shader Toy. The inspiration to experiment came from the ro.me and Angry Birds announcements at Google I/O. It's exciting that WebGL, canvas, and HTML5 are gaining momentum.
When starting development on a new game, creating a concept video or a playable prototype can be extremely useful. The bigger the project and the larger the team, the more useful the video or prototype becomes. Traditionally, written design documents have been used to describe developer ideas. While a written document can be useful, the concept video excels in a few areas:
Quickly get viewer feedback as to whether the game looks fun. Not sure whether to spend millions of dollars on a risky game concept? Create a concept video and post it online. Measure the view count and read the comments. Viewers will be brutally honest and you will quickly find out if they love it, hate it, or are indifferent. The Limbo developers posted their concept video online several years before they shipped the finished product. Better yet, numerous indie developers have bypassed the video altogether, created a playable prototype, and released it online. The prototype gains enough attention and praise that they decide to turn it into a full fledged game.
Provide the development team with a concrete vision. The downside of a written document is that it leaves too much room for imagination. Each team member will read the same document but end up with a different vision in their mind. A concept video leaves less room for imagination and points the team in a common direction.
Provide more detail, quicker. Getting each team member to sit down and read a 10, 20, or 100 page document and remember all of it is tough. Watching a 1-2 minute video is much quicker and has greater information density. (A picture is worth a thousand words?)
Illustrate a concept or feature that might be too hard to describe on paper or might not sound fun. An art style may be unique enough that it is difficult to describe. A gameplay feature might be difficult to imagine because it has never been done before. Sometimes showing them is the only way to turn them into believers.
Realistically, you won’t be forced to choose between a design document and a concept video. They can serve different purposes and be made to complement each other. However, showing someone a concept video or letting them play a prototype is one of the best ways to gain support for your game idea.
Well, I think a lot of people put too much emphasis on the epiphanies. Epiphanies are there, you do get them where you see clearly into something and all that. But it really is true that most great works aren’t a result of epiphanies, they’re the result of lots of hard labor. That is a trap that a lot of people fall into where you think that the epiphany is the important thing. Sometimes it is, but in 95% of cases it’s just a matter of smooth, calm integration of everything you know.
It’s not the one brilliant decision, it’s the 500 smart decisions that really make things good. It’s more a matter of being able to keep making smart decisions. Making one brilliant decision and a whole bunch of mediocre ones isn’t as good as making a whole bunch of generally smart decisions throughout the whole process. And there’s so many of them that have to be made.
Even at the end of Quake 3, I had a to-do list of a thousand things that could potentially be improved on. So it’s a matter of going through and knowing all these things that could be done, and prioritizing what the "sweet spots" are. Like "This amount of effort would get this batch of things done and it would have this side effect." Or "it would take all day to do this thing but it would probably destablize something else, so I’m not going to do it."
When you hear stories about John Carmack, it's easy to assume you'll never achieve his level of success because he's a genius programmer. Even though Carmack might have quite a bit of "natural" ability, that's not where he credits his success. And I don't think it's because he's being modest either. According to that quote, the qualities he finds most valuable are:
1. Hard work.
2. Consistently making smart decisions.
3. Prioritizing your time and effort correctly.
I think these qualities can be achieved by any developer. Sure, they might not be easy. But as games become more and more complex, they are only going to become more valuable.
The most important theme I observed at GDC 2011 was: good tools are what make the difference. Funny considering I didn't attend any talks that were specifically about tools.
Playdead's level design talk revealed that their real-time level-building tools were what allowed them to quickly create, test, and iterate on Limbo's puzzles. This speed of development allowed them to create enough content that they were able to discard approximately 70% of their puzzles and only keep the cream of the crop.
In the Halo Reach networking talk, David Aldridge said that debugging tools are what allowed Bungie to reduce bandwidth requirements to less than 20% of Halo 3's. Adding the ability to splice network profiling data into their recorded game sessions let them play back traffic data along with game data. This profiling data could be viewed at any point in the replay using a graphical overlay. Alridge said these tools took about 6 weeks to implement.
In her SPU-Based Deferred Shading talk, Christina Coffin stated that good debug visualizations are key to both guiding their content optimization and validating the aggressive culling required by their complex scenes.
While development is in full swing, it's often hard to convince yourself and your team to invest the time and resources necessary to build an effective tool suite. These talks served as a great reminder that investing in tools can enable you to produce features and content that would not otherwise be possible.