Gantt charts suck.
They're great for work that's like manufacturing, where you have a clear assembly-line perspective on how the work is supposed to be done. Gantt charts are useful for resolving dependencies between different parts and finding out what the gates on development are.
But programming isn't manufacturing. It's not engineering, either. I'm a big proponent of software engineering, but that body of knowledge is more like disciplined craft than engineering. An engineer can plan out what needs to be developed, what each piece needs, and how long each piece will take to build. He can make you detailed drawings on how the piece looks. He'll give you the formulas for all the chemical reactions that go on in your plant. He'll tell you how strong that girder needs to be to hold the weight and stress that will be put on it.
But programmers can't do that. How long will it take to write the AI? Hah! The designers don't even know what the AI will do yet, or how complex the collision maps are, why would a programmer have any idea how long an AI will take?
I've written many different particle systems. I could clone one of my old systems fairly quickly, and also give you an accurate estimate of how long it would take to do. But no system exists in a vacuum. A particle system has to integrate with the underlying graphics engine. You might want to add some constraints to the system to prevent it from bogging down the CPU. And then there's always new features to add halfway through development.
If you ask me to build the same system that I built last year, then we're getting close to engineering. If I built that same system a half-dozen more times, it'd be the sort of streamlined, organized project worthy of being called engineering. But hah! And hah again! The technology moves to fast for that to happen.
New systems are research projects. If we could properly schedule research projects, then we'd have a cure for cancer already. We woulda had one decades ago. But research isn't like that, and most systems in games are new systems, similar to last year's model but with a new twist. There's no good way to figure out how that twist will effect the project until it's built, though.
And that brings us back to agile development. Scheduling is just a loopy fallacy. If it wasn't for programmers being exempt employees (or employers dodging the law and refusing to pay overtime)... well, actually, I think that's the sort of mess that would force a lot of people to reassess how they schedule programming.
An iterative model means frequent releases. Agile development means prioritizing features. You might not know when everything you want will be done, but at least you'll be sure the important bits were done by the time you need to ship.
I'm working on a little sprite editor this weekend. I need both a subset and superset of the tools that most paint programs have, so I'm just building my own. (I wrote my first paint program for the Atari 800 around twenty years ago.) At one point, I was tempted to write down all the tasks that I needed to complete before I considered the editor done, then decided to throw the list away. I don't really need to know when the tool will be done. I know what's important, and I'm doing the big, obviously important stuff first. Things like frickin drawing. Saving, loading, color picking.
I'm not trying to build the uberest components ever, before the app runs. I'm not amassing giant graphics libraries, full of all the latest algorithms and hippest widgets. Screw that. If I need that stuff, I can add it when I need it. Right now, I need a way to use an Eyedropper without having to take my hand off the mouse, or reach across the keyboard (usually meaning looking at the keyboard), with the chance for error and time wasted. That feature? That's in already! Although minimally functional, it's already useful.
And hence another problem with schedules: you might have the most accurate schedule known to man, but if your programmers are busy adding features that no-one will ever use, then you've wasted their time. Your project is less likely to succeed because you were more worried about being 'done' on time than you were about what you had working.
The stuff that slows down programming, for me, is almost always completely outside the scope of programming. Things like 3rd-party libraries being incompatible (from things like XNA not building under Visual Studio 2008, to creating MS Exchange mailboxes on Vista requiring not a simple code library like in XP but a completely separate scripting system). That shit set me back days, on tasks that were, otherwise, only a few hours long. On my current game, the conversation editor took me over a week to complete, when nearly every single other editor took on the order of 3 hours. Why? The design kept changing. (My designer is a fucktard. But all the chicks say he's sexy so I'm stuck with him.)
So, you might ask, how in the world can you schedule if you can't schedule? Again with the iterative development: you'll be releasing on a regular basis anyway. If you have a drop-dead ship date, quick iterations mean you'll have something steady. Prioritize the tasks that you give your programmers, and they'll get the important stuff (and the low-hanging fruit) done. The better your programming team, the more features you'll have at ship. And because they released new builds all the time, it'll also be a robust game.
Showing posts with label management. Show all posts
Showing posts with label management. Show all posts
Saturday, June 7, 2008
Thursday, May 29, 2008
Programmers as Designers
First let me point out that there are many game-building tasks that are given to a designer. The designer might come up with a world history, write character dialog, design levels, tweak game mechanics, design game mechanics, name classes or skills, come up with crafting recipes, write game-item scripts, and on and on.
Here, I'm talking about the high level stuff -- mechanics, and the other stuff insofar as it is relevant to the feel of the gameplay experience. The gestalt of (say) level design, rather than the craft of it.
--
Programmers, by the nature of their job, have a great body of experience to draw from; a rich source upon which they can draw insight into the game design process.
Let's say you want dynamically flowing water in your mostly-2D city building game. You can ask a programmer about it, and work with the programmer. But what works, the caveats, etc are all things discovered by the programmer. Having someone else (a separate designer) stare over his shoulder just wastes his time -- unless you think it's important to prevent that programmer from working without adult supervision. :P
Some programmers are eggheads. Total geeks. Socially inept, clumsy, absent-minded, the works. These guys might be good at algorithms, but you don't want to let them near your design. My argument isn't that being socially inept makes someone a game designer. Quite the reverse. My argument is that a rational mind is critical for the task.
A good designer needs to understand [1] how algorithms will impact gameplay; [2] what drives players, what they think of as fun, and what makes games compelling; and [3] how the mechanics he's built into the game will alter and steer player behavior.
Algorithms
I've met some designers that are great at level design. True artists. But their levels were sometimes awkward and unbalanced. I wouldn't want to ask them to come up with game mechanics, other than to contribute some creative suggestions. They were no better at designing game mechanics than dozens of the egghead programmers I've worked with, but the engineers understood Big O, searching, sorting, curves, graphs, charts, A*, inheritance, and/or state machines.
Compelling Gameplay
A good designer needs to understand how people think. Coming up with cool ideas isn't useful if you're the only one that thinks they're cool. I've said before (and this might well be a recurring them) that most players have no idea of why they like a game. It's easy to take something and criticize it. When you don't actually have to implement anything, it's also easy to suggest solutions. I'm reminded of suggestion threads on popular-game bulletin boards. There's a ton of people with theories for making the game more awesome or less sucky, and a ton of theories that just won't work.
This isn't something that a programmer would be better at than an artist or level builder, generally, except that I think a programmer is closer to learning about this stuff, because good programmers are good at analysis. They understand the scientific method, and how to test their own theories on player behavior. Some designers spend a lot of time studying game mechanics; some programmers do too; either one might also spend time studying psychology.
Incentives
Game designers get to play Economics Czar, but people are bad economists. Politicians will tell you "we're doing this for the children" and wind up with a plan that stabs them in the back. A game design sets up incentives, which players will quickly discover and play to. Learning to look for and see incentives before they're implemented in a game isn't something that happens after reading one blog page. A book might help.
As with creating compelling gameplay, I think this is one of those areas that programmers are often not any more competent than anyone else in a game studio, but yet an area where their mindset and experience with code (and scripting) can give them a head start in learning it.
The Biggest Barrier
I think the biggest hindrance to creating great game mechanics, for non-programmers, is not knowing what's possible to do in code. I'm an agile developer, and I think one of the key life lessons that's pushed me in that direction is learning that you find out far more about a problem by trying to implement it than you ever could be staring at it while it's on a piece of paper. When I was in college (and for years afterwards) I thought the most important thing a programmer should do is plan out his development path in excruciating detail. Implementation turns that detail to excrement. For years my plans never turned out the way I thought, and, like a politician addicted to money, thought the solution was to throw ever more at the problem.
But the lesson isn't to not plan; it's to acknowledge that you need to jump in and get your feet wet, to find out if the rock you see underneath those rippling waves is as sturdy as you think it is. Staring and planning and measuring from the streambed will give you a better idea, but not the answer.
Programmers are the ones charged with finding away across that stream. I think the experience of doing the grunt work gives the grunt a great perspective for planning the next one. It's up to the programmer to put that experience to work.
Here, I'm talking about the high level stuff -- mechanics, and the other stuff insofar as it is relevant to the feel of the gameplay experience. The gestalt of (say) level design, rather than the craft of it.
--
Programmers, by the nature of their job, have a great body of experience to draw from; a rich source upon which they can draw insight into the game design process.
Let's say you want dynamically flowing water in your mostly-2D city building game. You can ask a programmer about it, and work with the programmer. But what works, the caveats, etc are all things discovered by the programmer. Having someone else (a separate designer) stare over his shoulder just wastes his time -- unless you think it's important to prevent that programmer from working without adult supervision. :P
Some programmers are eggheads. Total geeks. Socially inept, clumsy, absent-minded, the works. These guys might be good at algorithms, but you don't want to let them near your design. My argument isn't that being socially inept makes someone a game designer. Quite the reverse. My argument is that a rational mind is critical for the task.
A good designer needs to understand [1] how algorithms will impact gameplay; [2] what drives players, what they think of as fun, and what makes games compelling; and [3] how the mechanics he's built into the game will alter and steer player behavior.
Algorithms
I've met some designers that are great at level design. True artists. But their levels were sometimes awkward and unbalanced. I wouldn't want to ask them to come up with game mechanics, other than to contribute some creative suggestions. They were no better at designing game mechanics than dozens of the egghead programmers I've worked with, but the engineers understood Big O, searching, sorting, curves, graphs, charts, A*, inheritance, and/or state machines.
Compelling Gameplay
A good designer needs to understand how people think. Coming up with cool ideas isn't useful if you're the only one that thinks they're cool. I've said before (and this might well be a recurring them) that most players have no idea of why they like a game. It's easy to take something and criticize it. When you don't actually have to implement anything, it's also easy to suggest solutions. I'm reminded of suggestion threads on popular-game bulletin boards. There's a ton of people with theories for making the game more awesome or less sucky, and a ton of theories that just won't work.
This isn't something that a programmer would be better at than an artist or level builder, generally, except that I think a programmer is closer to learning about this stuff, because good programmers are good at analysis. They understand the scientific method, and how to test their own theories on player behavior. Some designers spend a lot of time studying game mechanics; some programmers do too; either one might also spend time studying psychology.
Incentives
Game designers get to play Economics Czar, but people are bad economists. Politicians will tell you "we're doing this for the children" and wind up with a plan that stabs them in the back. A game design sets up incentives, which players will quickly discover and play to. Learning to look for and see incentives before they're implemented in a game isn't something that happens after reading one blog page. A book might help.
As with creating compelling gameplay, I think this is one of those areas that programmers are often not any more competent than anyone else in a game studio, but yet an area where their mindset and experience with code (and scripting) can give them a head start in learning it.
The Biggest Barrier
I think the biggest hindrance to creating great game mechanics, for non-programmers, is not knowing what's possible to do in code. I'm an agile developer, and I think one of the key life lessons that's pushed me in that direction is learning that you find out far more about a problem by trying to implement it than you ever could be staring at it while it's on a piece of paper. When I was in college (and for years afterwards) I thought the most important thing a programmer should do is plan out his development path in excruciating detail. Implementation turns that detail to excrement. For years my plans never turned out the way I thought, and, like a politician addicted to money, thought the solution was to throw ever more at the problem.
But the lesson isn't to not plan; it's to acknowledge that you need to jump in and get your feet wet, to find out if the rock you see underneath those rippling waves is as sturdy as you think it is. Staring and planning and measuring from the streambed will give you a better idea, but not the answer.
Programmers are the ones charged with finding away across that stream. I think the experience of doing the grunt work gives the grunt a great perspective for planning the next one. It's up to the programmer to put that experience to work.
Monday, May 19, 2008
Focus
What's the purpose of my current game development project? Do I have a clear focus, or is it more like the focus of a lightbulb? What's my feature list -- don't I want every feature imaginable?
I recently started work on a long-standing RPG side project. While working on it, I've done "research" into other indie RPGs, and played some roguelikes.
Roguelikes are great indie game developer fodder. The devs can release a new version whenever they want without worrying about people currently in the middle of a play-through. The major branches (NetHack, Rogue, Moria, Angband) and the vast majority of their derivatives (excepting the elephantine Diablo) are open source, so the dev can see what everyone else is doing. And the standard UI--a text-based console display--is trivially simple to code for.
One consequence is that any roguelike can borrow code from any other roguelike. (Mostly.)
So let's say you're developing a tile-based RPG with a simple UI and simple combat, but not random levels or permadeath. Or let's say that I'm developing one. What features do I include?
In the major roguelike branches, development is never finished. There's always new creatures, new weapons, new dungeon generation algorithms, new player races and classes, new skills, and on and on. But that's not me. My goal is to finish a game and push it out the door. My game has a story, which would kill a roguelike. Imagine playing through Tetris and having to listen to the unfolding of some complicated plot. After a few games, the early bits of the story would get horribly boring. After a few days, you'll want to turn it off. After a few weeks, you'll stop playing the game because that story (no matter how well-written) has become impossibly repetitive.
But story isn't the only reason to reign in features. I want to release the game and have it be done; I don't want to endlessly add new features to it. Bugfixes are fine, but new features go into the sequel. My goal with this project is more to release a finished RPG than almost anything else. I've never finished this "project", though it has changed forms and been restarted so many times that it no longer resembles the idea I had back in high school.
Do roguelikes require focus? I don't think it's necessary. They're a very different product. Does a word processor need focus? Not really; Office has grown so gargantuan that it does everything now. You can imbed spreadsheets, graphs, images, links, columns, whatever... It doesn't have a fixed feature set. Like an arcade game, it's used in small sessions, almost constantly. I've read of many novellists who use some arcane word processing machine or application on a historic old PC because they like it and they're used to it, but for the rest of us -- we can install the latest Word and get right to a new session. No focus here; who cares? There's no single feature that's a unique selling point for the product.
Focus isn't just a feature for small products. World of Warcraft has a focus (i.e. combat), and that's a huge game. Most console games have a very clear ending that serves as the focus for the player. I think the best games have a focus that helps them provide an entertaining experience without taking forever to develop. To me, the worst games¹ are those that try to do too many things. Sometimes that means trying to do just two things, like being both an RTS and an FPS, but doing neither well.
Focus is what lets me push off some cool feature til the sequel. Its what keeps me from spending another day searching the web for cool background graphics. Its what tells me to stop when I try adding more features to the combat system.
--
1: actually the games I hate the most are those where I can't express myself because of some dodgy UI design, whether it's sloshy controls or control lag or a useless camera. I don't care how awesome your mechanics are, if the controls frustrate me I'm just gonna throw the disc away.
Related reading:
Andrew Doull's post on the Game Development Arms Race
I recently started work on a long-standing RPG side project. While working on it, I've done "research" into other indie RPGs, and played some roguelikes.
Roguelikes are great indie game developer fodder. The devs can release a new version whenever they want without worrying about people currently in the middle of a play-through. The major branches (NetHack, Rogue, Moria, Angband) and the vast majority of their derivatives (excepting the elephantine Diablo) are open source, so the dev can see what everyone else is doing. And the standard UI--a text-based console display--is trivially simple to code for.
One consequence is that any roguelike can borrow code from any other roguelike. (Mostly.)
So let's say you're developing a tile-based RPG with a simple UI and simple combat, but not random levels or permadeath. Or let's say that I'm developing one. What features do I include?
In the major roguelike branches, development is never finished. There's always new creatures, new weapons, new dungeon generation algorithms, new player races and classes, new skills, and on and on. But that's not me. My goal is to finish a game and push it out the door. My game has a story, which would kill a roguelike. Imagine playing through Tetris and having to listen to the unfolding of some complicated plot. After a few games, the early bits of the story would get horribly boring. After a few days, you'll want to turn it off. After a few weeks, you'll stop playing the game because that story (no matter how well-written) has become impossibly repetitive.
But story isn't the only reason to reign in features. I want to release the game and have it be done; I don't want to endlessly add new features to it. Bugfixes are fine, but new features go into the sequel. My goal with this project is more to release a finished RPG than almost anything else. I've never finished this "project", though it has changed forms and been restarted so many times that it no longer resembles the idea I had back in high school.
Do roguelikes require focus? I don't think it's necessary. They're a very different product. Does a word processor need focus? Not really; Office has grown so gargantuan that it does everything now. You can imbed spreadsheets, graphs, images, links, columns, whatever... It doesn't have a fixed feature set. Like an arcade game, it's used in small sessions, almost constantly. I've read of many novellists who use some arcane word processing machine or application on a historic old PC because they like it and they're used to it, but for the rest of us -- we can install the latest Word and get right to a new session. No focus here; who cares? There's no single feature that's a unique selling point for the product.
Focus isn't just a feature for small products. World of Warcraft has a focus (i.e. combat), and that's a huge game. Most console games have a very clear ending that serves as the focus for the player. I think the best games have a focus that helps them provide an entertaining experience without taking forever to develop. To me, the worst games¹ are those that try to do too many things. Sometimes that means trying to do just two things, like being both an RTS and an FPS, but doing neither well.
Focus is what lets me push off some cool feature til the sequel. Its what keeps me from spending another day searching the web for cool background graphics. Its what tells me to stop when I try adding more features to the combat system.
--
1: actually the games I hate the most are those where I can't express myself because of some dodgy UI design, whether it's sloshy controls or control lag or a useless camera. I don't care how awesome your mechanics are, if the controls frustrate me I'm just gonna throw the disc away.
Related reading:
Andrew Doull's post on the Game Development Arms Race
Subscribe to:
Posts (Atom)