When I was 11, my family got its first computer: an AST “Advantage!”, which sported a 66 MHz 486 processor, 4 MB ram and 32 MB of hard drive space. It wasn’t the greatest computer, even for the time, but it did have QBasic on it, and having always wanted to make games, I immediately dove into coding.
I stuck with QBasic for the following decade or so simply because I was comfortable with it. I made a bunch of shooters, platformers, and actually a lot of weird games. I made one called “Kill the Innocent” (download it here, but you’ll need DosBox to make it work), which featured stick figures walking along a bridge, and you aim a gun at them and just kill them. I remember coding a detailed system for how the man’s top-hat would float gently to the ground, and a very simple physics system that would allow you to juggle the man’s head in mid-air with shotgun blasts. (I guess I was subtly picking up on the ugliness of violence in videogames even back then, although I certainly wasn’t conscious of it, being that my AST Advantage was running Doom so often.) Continue reading →
While it’s tempting to think otherwise, computers are the best tool we have for pursuing great game designs. In this episode, I also talk about how “abstract” games are problematic due to low information density, the information horizon, and a lot about the medium of board games.
Episode 2, already!? Yep! I spent essentially all day one day recording both of these episodes, because I wanted to really get the ball rolling. It’s kind of annoying to have just one episode of a podcast, I feel like.
Today’s episode deals with the distractions and other obstacles that have slowed our growth in the path to progress in game design. I think I’ve gotten much more into the groove with this episode – now with fewer “ums” and less housekeeping!
Here’s a few things I said I’d link to in the show notes:
There are a few philosophical positions on game development that are, I would say, “anti-design”. In this short series, I will go through a few of them. We’ll begin with an article about what I call “the quantity design philosophy”.
Recently there was a discussion on the Google+ development group for the game Hoplite. The creator, Doug Cowley, is making some improvements to the late-game and asking people for advice.
Then, sort of in the middle of the discussion, another game developer chimed in with:
“At some point you’ll have to accept that it’s impossible to make a perfect game and stop tweaking 🙂 (Also, make more games!)”
This statement really angered me, precisely because it’s such a common sentiment in the world of game development these days. Perfect can indeed be the enemy of the good, but really, who’s even going for “perfect”? Are any games you’ve ever played in danger of being “perfect”? Perfect, in this context where a person is simply trying to do the right thing and improve their game, is a strawman.
I’m writing my book, so I don’t have time to write a big thing today, but I wanted to share a little thing I found.
I’ve often made claims that not only are we (everyone) collectively very bad at game design, but that large segments of our population do not even know/acknowledge that game design is a discipline all its own, separate from programming, art, or other elements of game development to begin with.
There are actually even university programs with “Game Design” in their titles that actually have nothing to do with game design. Take a look at this nice, horribly wrong infographic I found in my research today.
It’s from a website called “schools.com”, so I guess that’s kind of authoritative, and the infographic itself is nicely put together. Apparently, a game designer does the following things: