You have a system. Let’s say it’s a system where you can throw darts. And you have to open your bar in one week.

Throwing darts might have a bad interface. The dartboard might be too small or too big or poorly lit. Darts may be a perfectly nice idea, but the implementation of it needs tuning.

At this point, you have a feature, but not fun. It’s gonna take you four days to make it fun.

Read the rest of this entry »

A fair amount of folks have taken the last few posts (on making games more cheaply and on rigid programming philosophies) to a bit of an extreme further than I intended. So in the spirit of contradicting myself, here are some good reasons to write new code.

When you have something new to learn.

I still remember how proud I was when I independently invented the bubble sort in response to a problem. Then how baffled I was when I tried to figure out how quicksort works.

Writing your own version of a known solution is a fantastic learning tool.  Trying to learn how to write jazz progressions? Grab a jazz song, change the key, and start modestly tweaking the chords (an 11th into an augmented, or whatever). Then build your own melody on top of it. Trying to learn how to draw? Start copying people who know how. Trying to figure out how a given game genre works? Try cloning or reverse-engineering a game in that genre. It’s a classic method of learning and there is no shame in it. If you have any creative spark, you’ll quickly move past this sort of journeyman work and start adding your own elements to it. (This is one of my caveats to Dan Cook’s post on game cloning).

Read the rest of this entry »

I only offered 6 points, but 3 of them are ones that people are wanting to argue about! I suppose that is a pretty good hit rate…

A few folks took exception to my comment that “code doesn’t rot, our ability to read it does.”

The first objection is that most code is born rotten, that it is rare to find code written to the standards that allow it to be easily maintained. I can’t really argue with that, though of course there are plenty of practices that ameliorate this: code reviews, code standards, etc. I’d answer with “that’s just code where our ability to read it perished as it was being typed.”

The second objection is basically that platforms shift out from under code. This is absolutely true — but is also a sign that you’re not actively maintaining your codebase. Times of truly catastrophic platform shifts where everything you did is invalidated should be relatively rare these days, honestly.

Read the rest of this entry »

Rigid programming philosophies are the devil.

Look, I am upfront about the fact that I am not an amazing programmer. I am not even a really competent one. I hack. I didn’t go through a CS degree, I don’t actually know a lot of the lingo, etc.

On the other hand, I have in fact been credited as a programmer on published games. I have programmed in quite a lot of languages, I prototype my own stuff regularly, and my name is on several technical patents. I seem to have a knack for seeing architectural solutions to problems, and for inventing technical solutions. (I generally prefer to partner with a genius coder for the actual implementation thereof — and have been lucky enough to work with many of them!).

So take everything I am about to say with the appropriate grain of salt.

Read the rest of this entry »

There are basically two big things that drive a lack of innovation in games.

The first of them is risk minimization. The second of them is risk minimization.

The reason I say “two” is because some forms of mitigating risk are undertaken with intentionality: purposely making a game that is a clone, for example. This isn’t always a bad thing — sure, sometimes it is done in order to capitalize on a market trend, but other times it’s done to learn how a given genre works, and in that scenario it’s a common and vital tool in a designer’s toolbox.

But this post is about the second sort of risk mitigation, which primarily centers around the fact that as games get more ornate, they get more expensive to make. High upfront costs push you naturally and inevitably towards incremental changes, with the biggest risks being taken on content rather than game systems. This is a pattern that leads inevitably towards “genre kings” — and the stage after genre kings tends to be stagnation and loss of audience reach.

So how can we as an industry keep costs down? Well, here’s my take, somewhat more elaborated from my now long-ago presentation on “Moore’s Wall.”

Read the rest of this entry »

I forgot to blog about this when we released it, but I have some more of those handy little development tools that we’re releasing for Metaplace available here for you. There’s a particle editor that spits out sprites so you can bring them into 2d worlds easily, and there’s an animation strip editor that helps you make sprite sheets. Both of them are only available for Windows right now — sorry! — but they’re fun to mess with and might be useful to you even outside of a Metaplace context. You can grab them here. They’re basically unsupported, since I do them mostly in my free time.

Some screenshots are below. There’s full docs in the tools.

Read the rest of this entry »