The following is an adaptation of a message I posted to the gamedesign-l group on Yahoo! Groups. It's some advice for an aspiring game programmer.

Most game programming students (and artists too) have a lot of interesting ideas in their heads about the cool games they want to make one day. You might have played various games and found a lot of room for improvement, and you probably want to address these kinds of deficiencies in the games that you will be making.

The best thing to do right now is to become proficient at programming, and all the other subjects that go along with making a great game.

If you're a student, you'll have some nice opportunities to select classes on these topics, and if you're a hobbyist, then you'll have to guide your own study of:

Logic
Programming is all about logic. Game design, which is about creating the rules for how the game plays, also involves much of that same logic and planning.

Math
The real world operates on strict rules, your game will abide by these rules or manipulate them in some way. Physics, Geometry, and Trigonometry are important for this, as is Economics.

Music
The proper use of sound enhances the gaming experience.

Art
Games use 2D or 3D artwork and you need to know the techniques involved in displaying art and animation. Develop your aesthetic side and art skills because it will help you understand and enhance the work that artists do. It will also help you make some good art of your own when you're making a game by yourself.

Psychology
Not necessarily to solve people's mental issues, but a familiarity with human behavior helps to know just a little bit about what's going on inside a player's head so that you can better tailor the game experience. You might also find this useful when working on AI, but not for the reason that probably just popped into your head.

Literature, Film
The only way to understand the elements of a great story is by getting exposed to plenty of them. As good as you think your game's story and plot are, you might find that your storytelling improves as you become more well-read.

History
Many games involve story telling of some kind, and you'll find that history provides a lot of ideas.

I'm sure others can contribute some more ideas about topics that should have been listed, or have additional ideas as to how any of these are important or less so.

A good way to direct your journey into learning about game development is to take an idea you already have and plan out that game. You'll eventually figure out what areas you need more information about, and you'll eventually get that knowledge and move on to the next hurdle.

In the end, you'll have your game, or have made smaller games along the way.

Bad usability is like a leaky pipe or driving or a road riddled with potholes.

I am famous for my car analogies. Most people get them immediately because they all have experience with cars, and I've been able to come up with some good examples that helped people understand some really complicated things.

Here's a great non-car analogy from 90 Percent of Everything: bad usability is like a leaky pipe.

The author explains that if there are too many opportunities for the user to get lost or make mistakes, then you might not see as many customers completing the transactions you were hoping for at your web site. This is applicable to applications too.

The article includes a graphic that shows how a lot of water might drip out on its way to the tap. Each drip represents a usability "leak" such as "What does that error mean?" and "What do I do next?" What you get at the end is not the complete volume that was supposed to come through but just the amount that managed not to drop out along the way. Imagine losing 60% of your customers simply because they got lost on the way to completing the sale! What is the likelihood of them coming back for more?

My car analogy would probably be about potholes, and I'd say something along the lines of...

If the drive to your store is always characterized by potholes, detours, traffic, or other undesirable incidents, then drivers are likely to choose much more comfortable alternate destinations even if those destinations only offer a portion of the things the original destination promised.

In other words, your store might lose a sale, and maybe a customer for life if your product's usability stinks.

It's bad enough when heavy rains cause the potholes, but it's worse when the potholes are of your own creation.

It's easy for a programmer to become oblivious to usability holes. The assignment might have been broken down into tangible sub-tasks, and somewhere along the way, there is no check to evaluate the whole solution to see whether it is "correct" in all dimensions. It may employ the best possible algorithms and a pass a peer review, but what about the user's review? Does the solution work for the user?

Users don't care why your program is fast or slow, they just know that it is.

Users don't care why something can't be clicked or can't be scrolled, they just know that they'd like to click or scroll those things.

What they care more about is not whether your task was completed on schedule and budget, but whether theirs will be.

It's especially bad when a competing product or service might do a better job at providing those same features, because the user will need more justification to keep using yours. As stated by Raymond Chen at The Old New Thing blog, "it doesn't matter how great your 1.0 system is if you don't survive long enough to make a 2.0."

No matter how magnanimous your supervisor claims or wishes they could be, the reality of life is that you have to meet deadlines and get some code turned in. Do what you can to ensure that you are truly solving the customer's problems and not just your own, or else there may not be any customers/clients, and eventually no deadlines at all because there's no product to work on.

Software is like carpentry.
Given the user's requirements, programmers can probably build whatever is being asked for. It might look ugly, but if that's what the end user wants, and they're happy with the resulting product, then success, and profit! Sometimes you create a thing of beauty, and then success, and profit! In general, nobody wants to make something ugly, but circumstances might take that end result out of our control. (I refer you to the numerous articles at The Daily WTF for some examples)

One of the advantages of working with wood is that you can handle it pretty easily and fix constructions issues quickly. Things with steel are not the same. Steel isn't something you just casually pick up in your car or truck at a construction store, and it requires lots of other machinery (and people) to make things with. Now there's nothing wrong with steel as a raw material, but it means that you need to have anticipated a lot of things in advance and make some very great plans. Unfortunately, it also compromises your ability to adapt to changing requirements (and externally imposed limitations such as building codes), and it's entirely possible that if the design and plans are too inflexible, then you're going to be forced to generate a result that's not making everybody happy.

Building software is a little like that. Large projects need to be planned out well, the design needs to be in place and employees need to have some semblance of a strategy so that the business managers can figure out how everything gets paid for. However, one thing we have in software that they don't have in architecture is that we don't build our skyscrapers with steel.

The pliability of our raw material is great. It means we can still be responsive and address unforseen issues with less hassle than if we had built things out of steel. It doesn't mean that we can or should build our skyscrapers crooked on a whim, but it does mean that programmers have some room to make adjustments.

My big deal about this wood example is that your end result is what matters. Sure, it needs to be on schedule and budget, but it also needs to solve the problems that it was supposed to. And it should solve those problems well and your end users should be happy.

Instead of coming up with reasons to disprove why a new feature can't or shouldn't go in, just listen to your customer and take notes. You don't have to come up with the answer in that same instance, but just make sure you properly understand the problem being described. This is just as much about people skills as it is about technical prowess. Quite often, a non-technical user has a slightly different understanding of your system, and the solution might just be to move some UI elements around, or add new parameters.

One of the things that I do in my own coding is to account for future extensibility right there in my functions. For example, passing objects and data structures gives you a silent way to upgrade your system. A trivial example would be a function that calculates averages. An interface like:

float CalcAverage( float f1, float f2, float f3, float f4 );

is limited to only handling a fixed set of inputs. If your needs change, you'll have to track down all the places where this function was called and update them. If it's a large project, you might even miss some modules and be forced to revisit your updates later.

Worse yet, someone (hopefully not you) might cut-and-paste from this function to create variants for other uses. This means that certain kinds of bugs or other problems in the original can propagate to other functions, and the QA complexity has just increased.

Consider an interface like:

float CalcAverage( FloatArray f );

It's much more flexible. I'm not going to explain why because I didn't intend this to be that basic of a programming chat.

Build a reasonable amount of flexibility into your systems at design time. You'll greatly reduce the ramifications of changing requirements. It's much easier to maintain this kind of code, and you'll definitely get more work done.

Going back to the wood vs. steel analogy, software solutions have a lot of room for flexibility. Unlike the business of building skyscrapers, we have more freedom to change lots of things as we go along. It doesn't mean that we should (because that might throw the project way off schedule, or our product might lose its focus), but we should be responsive to the end user's needs and the project's goals. There's no point in releasing something useless, is there?

Me neither!
Like most people, I looked forward to reading the newspaper comics as a kid. There were always a few that I never really got into, like the dramatic serials, and then there were those funnies that I just never understood. I figured that some like Andy Capp were over my head because I was a kid, and Peanuts was only funny now and then, but I figured that was because my lifestyle did not match Charlie Brown's.

Now that I'm older and have acquired the inevitable life experiences, I am able to find the humor or the underlying comedic principle in many more of the comics that now appear in the newspaper comics, and even online. I've also homed in on a few comics that seem to always guarantee a chuckle or guffaw such as:

• Partially Clips
• Gary Larson's Far Side
• Dilbert
  

But then there's Marmaduke. I think my comprehension of the humor in this comic remains at the same 0.001% that it's ever been. Thanks to the internet, I find that I'm not alone:

• The Marmaduke Project
• Joe Mathlete Explains Today's Marmaduke

The only explanation I can think of for Marmaduke's "success" is that a lot more people own Great Danes or other very large dogs than we might imagine, and they can relate to the "humor" in the strip.