I always thought I was a good programmer because, you know, Dunning-Kruger. When I got my first programming job we were using a language of which I only had academic knowledge, and I knew I was out of my depth. I spent many weekends reading and studying and trying stuff out on my own in order to get up to speed and learn everything I could about this "Object Oriented" stuff.
A few years later, I got into the games industry. At the time, I had been following John Carmack's .plan updates, reading books and forums, and trying out computer graphics stuff at home. I had demos and knowledge, but even then, I knew that I was "the new kid" in a company filled with industry amateurs. Whatever I already knew about C++ and assembly and computer graphics, I was working with people that had already been in the games industry for years.
Same thing when I got into C# and Web Services, and then with ASP.NET, etc etc.
The difference between pros and amateurs is that pros do it 40 hours a week.
When I was in the games industry proper, I was typically involved in the interviewing process. Many of the candidates that I spoke to had no prior industry experience, but had taken some classes at school, or done some stuff on the side.
The difference between a year working for a game company and a year taking a class is astronomical. A class is three hours a week of instruction, and maybe that again on a project or homework -- and that's just to learn the basics. And you get the summer off, and a few weeks for Winter break, and so on. A year working for a game company is 60 hours a week working on games -- whether that's art or code or design. Plus whatever books you read on the side (for me, easily more than I ever spent reading textbooks in school). Plus the side projects you work on when you're home. Plus meals and recreation time with other industry insiders.
If you want to get into the games industry, don't read blogs for hours every night and think you're learning. The agile manifesto applies here as well: you learn more by doing than by thinking. Thinking through stuff is great, researching is fine, but there's no substitute for getting your hands dirty.
I remember Dave Sim (of Cerebus fame) saying something along the lines of "every artist has 3000 bad pages in him before he'll draw any good pages." Pretty much everything is like that. Sure, you play Guitar Hero on the weekends, but are you a guitarist? Hah, no-one really thinks that. It takes a couple years of practice before anyone would be willing to pay to hear you play. Art is the same way -- remember those art geeks back in high school? Some of them were pretty good. Not, like, professional good, but pretty damn good for high school students. It takes a lot of effort to get good at something. Games are, of course, the same as everything else!
I'm working on a few WinForms apps on the side, and building them has taught me far better than books. Books are great; they're a leg up. They point you in the right direction. But when you need to do something, having experience under your belt is a much better resource than a book. Some books are better than others in this regard. The Wrox ASP.NET 2.0 Problem - Design - Solution book is great, because you do something useful by following the examples. Reading it is ok, but actually building the samples yourself is much better.
And again, compare that you building your own app. Consider what the professional developer is doing -- he has to get something working. He's on a deadline. He's got a boss looking over his shoulder. He's got a client to impress. He's spending forty hours a week getting his hands dirty.
Are you?
If you want to get into the games industry, then take it seriously. Make it your hobby. Build games, code tools, craft models, paint textures, construct levels. And not just on the weekends, and not after spending the day surfing the web, doing "research."
Monday, August 11, 2008
Sunday, August 10, 2008
Quitting - Online Game Addiction
I'm addicted to Travian. I know it's a bad addiction. Yet knowing that, I still don't quit. I write that line and think, "is it really a bad addiction?" Why is it bad? If I could convince myself it's a bad thing, I'd have a much easier time quitting.
I want to do something else with my time, but I also want to preserve my investment in the game. I want to keep growing. I'm close to several big, short-term goals in the game, and I want to keep going until I get there. I don't throw away perfectly good clothes, or a working LCD monitor, or books, or even old computer games that I've already played. It's weird with a game, because what's there has value -- but only to me (but see below), and only in that game world. It's not like I could put this account up for sale on craigslist. It's like sentimental value in that regard, like a useless trinket purchased as a souvenir of a fun time that I once had.
I quit World of Warcraft three times. The first time was because guild drama made playing frustrating. The second time was because I wanted my life back. The third time I quit, it was because I lost interest in spending the time in the world and I found something else that I wanted to do more. I'm ok with playing games. It's like watching movies, or TV shows, or whatnot.
The thing about online-game addiction is that you can't really "sleep on it." I think it's best to quit cold turkey -- to announce to everyone that you quit and get on with your life. Often there's sufficient value in the game that you might want to preserve your progress, to sell your characters off or give them to friends. (No sense in all that value going to waste.)
That value is why I don't want to leave. I have a level of progress that others might envy. (Obviously a great many players wouldn't envy what I have, because they already have more. The same is true with level 70 WoW characters, for example. My point is that there are people, and a good number, that would want a shortcut to a high-level character and/or account.)
--
I decided to just take a break and leave the game for a few hours. It worked. I haven't deleted the account, but I don't feel the pull to sit and watch constantly. I don't know if a cold break is better than slowly toning down doses, but if the rest of me (ie my conscious mind) has decided that I don't want to play any more, then I just need to give it time. Eventually my desire to play will go away.
I want to do something else with my time, but I also want to preserve my investment in the game. I want to keep growing. I'm close to several big, short-term goals in the game, and I want to keep going until I get there. I don't throw away perfectly good clothes, or a working LCD monitor, or books, or even old computer games that I've already played. It's weird with a game, because what's there has value -- but only to me (but see below), and only in that game world. It's not like I could put this account up for sale on craigslist. It's like sentimental value in that regard, like a useless trinket purchased as a souvenir of a fun time that I once had.
I quit World of Warcraft three times. The first time was because guild drama made playing frustrating. The second time was because I wanted my life back. The third time I quit, it was because I lost interest in spending the time in the world and I found something else that I wanted to do more. I'm ok with playing games. It's like watching movies, or TV shows, or whatnot.
The thing about online-game addiction is that you can't really "sleep on it." I think it's best to quit cold turkey -- to announce to everyone that you quit and get on with your life. Often there's sufficient value in the game that you might want to preserve your progress, to sell your characters off or give them to friends. (No sense in all that value going to waste.)
That value is why I don't want to leave. I have a level of progress that others might envy. (Obviously a great many players wouldn't envy what I have, because they already have more. The same is true with level 70 WoW characters, for example. My point is that there are people, and a good number, that would want a shortcut to a high-level character and/or account.)
--
I decided to just take a break and leave the game for a few hours. It worked. I haven't deleted the account, but I don't feel the pull to sit and watch constantly. I don't know if a cold break is better than slowly toning down doses, but if the rest of me (ie my conscious mind) has decided that I don't want to play any more, then I just need to give it time. Eventually my desire to play will go away.
Labels:
addiction
Thursday, August 7, 2008
Powerful Players as Incentive
One of the things I mentioned in my previous post is the way that powerful players -- those with high scores, cool gear, and achievements -- serve as role-models to new players.
It is often not, strictly, the players themselves. It's not like they spent their lives getting good at a sport, or a musical instrument. We're talking gamers that spent too much time in a raid dungeon or playing their XBox and so did something that nearly anyone else could do, given enough time. "Role models" isn't the right word; I guess I'm hunting for a better one.
When I was playing WoW, I took a break after about a year of playing, then came back a couple months later. I remember talking to a new level-60 priest and he said I was regarded as one of the best priests on the server. I was definitely one of the best-geared, having played on that server since opening day, but best? How does he know?
I've felt the same way myself, about other accomplished players. And friends. I see someone with high scores, cool gear, etc, and I want to match them. Their accomplishment is a challenge to me, to do better myself, to match (or surpass) their score.
Knowing something is possible is a big part of the incentive to me; it's knowing that I could be even better. It's like, I think I do well and then see a bigger score, and say, "hey, I'm a good player, too, I should have a score that high." I want to have the high score but I'm not as concerned with letting people in my real life that I'm the one with that score; for me the draw is testing myself against a known measurement.
There's a lot of different incentives, really. One of the other incentives for me is closure, which drives collecting. It is an encouragement to get a full set of Tier X equipment in WoW, or to collect all the Pokemon, or have a full set of Magic: The Gathering rare cards from a certain set, etc. Other goals include wanting to be on top; to measure themselves; to crush other players; accolades; or keeping up with siblings or friends. I mentioned jealousy and greed yesterday.
These are all drives that come from seeing other players that have already achieved these goals; I'm not talking about the Achiever/Explorer/Socializer/Killer spectrum here. This isn't really just an achiever thing either -- at least, I don't consider it to be. My point isn't that players want to achieve these things, it's that they see other people that have achieved them and are motivated by that to go do it themselves.
The Lesson here is: make your achievements visible. Give players a chance to show off their
accomplishments. Make sure new players are exposed to the wide variety of power-ups in your game.
And the ways of going about that are plenty: leader boards, flashy gear, XBox Live-style achievements, and providing some way for high-powered and low-powered players to mix.
It is often not, strictly, the players themselves. It's not like they spent their lives getting good at a sport, or a musical instrument. We're talking gamers that spent too much time in a raid dungeon or playing their XBox and so did something that nearly anyone else could do, given enough time. "Role models" isn't the right word; I guess I'm hunting for a better one.
When I was playing WoW, I took a break after about a year of playing, then came back a couple months later. I remember talking to a new level-60 priest and he said I was regarded as one of the best priests on the server. I was definitely one of the best-geared, having played on that server since opening day, but best? How does he know?
I've felt the same way myself, about other accomplished players. And friends. I see someone with high scores, cool gear, etc, and I want to match them. Their accomplishment is a challenge to me, to do better myself, to match (or surpass) their score.
Knowing something is possible is a big part of the incentive to me; it's knowing that I could be even better. It's like, I think I do well and then see a bigger score, and say, "hey, I'm a good player, too, I should have a score that high." I want to have the high score but I'm not as concerned with letting people in my real life that I'm the one with that score; for me the draw is testing myself against a known measurement.
There's a lot of different incentives, really. One of the other incentives for me is closure, which drives collecting. It is an encouragement to get a full set of Tier X equipment in WoW, or to collect all the Pokemon, or have a full set of Magic: The Gathering rare cards from a certain set, etc. Other goals include wanting to be on top; to measure themselves; to crush other players; accolades; or keeping up with siblings or friends. I mentioned jealousy and greed yesterday.
These are all drives that come from seeing other players that have already achieved these goals; I'm not talking about the Achiever/Explorer/Socializer/Killer spectrum here. This isn't really just an achiever thing either -- at least, I don't consider it to be. My point isn't that players want to achieve these things, it's that they see other people that have achieved them and are motivated by that to go do it themselves.
The Lesson here is: make your achievements visible. Give players a chance to show off their
accomplishments. Make sure new players are exposed to the wide variety of power-ups in your game.
And the ways of going about that are plenty: leader boards, flashy gear, XBox Live-style achievements, and providing some way for high-powered and low-powered players to mix.
Labels:
game design,
status
Wednesday, August 6, 2008
Mini-Puzzles
I've talked of minigames before, in my previous post about game theory, but when gamers say "minigame" they mean a complete game-within-a-game. Run around in a platformer, take control of a gun emplacement, play Tetris or Breakout or Artillery, break down a wall -- then go back to running around.
The station-placement "minigame" in Transport Tycoon is somewhat gamelike, but the score is ephemeral. There's no win or lose; there's just "better" and "worse", and those measures are fuzzy. I think of it as a puzzle, since there is no opponent, no time limit. There's a goal, and a rough measure of score, and that's it.
What's great about Transport Tycoon is there's a ton of these puzzles in the game. Station placement, track placement, route optimization, and building fast & efficient intersections ("junctions" in the parlance) are all puzzles. And I like puzzles. :) I've got a handful of Hanayama cast puzzles on my desk at work, burrs and other wooden puzzles at home, and I can solve a Rubik's cube. So the game fits me.
One of the main differences between mini-games and mini-puzzles is that the puzzles are integral to gameplay; they are almost meta-games, in that doing such puzzles well achieves a goal beyond what the game sets for you. There's a group of players obsessed with crafting elegant junctions -- both fast and eye-pleasing.
This is definitely the sort of mechanic that makes every game better. Not every player needs to enjoy it; seeing the creations of others is an incentive to try your own hand. These complex junctions are inspiring. As with seeing high-level players in WoW, or the high scores on your favorite XBLA game, knowing it is possible is encouragement to try it yourself. Whether it's jealousy or greed or curiosity or admiration that drives players to achieve the same power doesn't matter. Because your players want to play more.
Would you rather make a game that other designers rate highly, or a game that players love?
My answer is, clearly, the latter. I'm offended--morally offended--by designers that look at games like Myst or The Sims and say "I don't know why people like those games, they're so stupid." That's a topic in itself that I might discuss later but let's gloss over it for now.
Or maybe not. My point of view is not to make games because I want to express myself as a designer -- I want to make something that people will enjoy. Some money would be nice, too.
My goal in this post and in this blog (as it relates to game design) is to figure out how to entertain players.
So back to the topic: I think minigames are 'cheating'. It's easy enough to 'design' a minigame because they are, generally, just executions of known designs. There's some GBA title that I remember being mentioned on Penny-Arcade that's like a billion different 15-second minigames so obviously there's room to stretch. (I feel like I should go look that game up.) Part of the power of the minigame comes from a player's experience with the genre of minigame, however. The power of a minipuzzle by contrast is that it forces the player to make a decision about how he is going to play the game proper.
Take track layout in Transport Tycoon. Building a cheap but speedy rail line around a mountain is no easy task. Yet how that player builds the line affects how his game develops -- if there's enough of a detour to go grab another town easily, if his line will be easy to upgrade, if he needs to buy different engines just to handle this one tricky stretch, etc. And basic stuff like how much he spent on it, and how efficiently the mountain line gets goods to and from each side of the hill.
--
Now, do I have a conclusion? Hmm. The lesson, if any, is "add minipuzzles." The tricky part is how. Sounds like a good future topic, eh? Part II in this series explores several good minipuzzles and examines what makes for a good minipuzzle. Part III, not yet written, will look at ways to add and improve minipuzzles.
The station-placement "minigame" in Transport Tycoon is somewhat gamelike, but the score is ephemeral. There's no win or lose; there's just "better" and "worse", and those measures are fuzzy. I think of it as a puzzle, since there is no opponent, no time limit. There's a goal, and a rough measure of score, and that's it.
What's great about Transport Tycoon is there's a ton of these puzzles in the game. Station placement, track placement, route optimization, and building fast & efficient intersections ("junctions" in the parlance) are all puzzles. And I like puzzles. :) I've got a handful of Hanayama cast puzzles on my desk at work, burrs and other wooden puzzles at home, and I can solve a Rubik's cube. So the game fits me.
One of the main differences between mini-games and mini-puzzles is that the puzzles are integral to gameplay; they are almost meta-games, in that doing such puzzles well achieves a goal beyond what the game sets for you. There's a group of players obsessed with crafting elegant junctions -- both fast and eye-pleasing.
This is definitely the sort of mechanic that makes every game better. Not every player needs to enjoy it; seeing the creations of others is an incentive to try your own hand. These complex junctions are inspiring. As with seeing high-level players in WoW, or the high scores on your favorite XBLA game, knowing it is possible is encouragement to try it yourself. Whether it's jealousy or greed or curiosity or admiration that drives players to achieve the same power doesn't matter. Because your players want to play more.
Would you rather make a game that other designers rate highly, or a game that players love?
My answer is, clearly, the latter. I'm offended--morally offended--by designers that look at games like Myst or The Sims and say "I don't know why people like those games, they're so stupid." That's a topic in itself that I might discuss later but let's gloss over it for now.
Or maybe not. My point of view is not to make games because I want to express myself as a designer -- I want to make something that people will enjoy. Some money would be nice, too.
My goal in this post and in this blog (as it relates to game design) is to figure out how to entertain players.
So back to the topic: I think minigames are 'cheating'. It's easy enough to 'design' a minigame because they are, generally, just executions of known designs. There's some GBA title that I remember being mentioned on Penny-Arcade that's like a billion different 15-second minigames so obviously there's room to stretch. (I feel like I should go look that game up.) Part of the power of the minigame comes from a player's experience with the genre of minigame, however. The power of a minipuzzle by contrast is that it forces the player to make a decision about how he is going to play the game proper.
Take track layout in Transport Tycoon. Building a cheap but speedy rail line around a mountain is no easy task. Yet how that player builds the line affects how his game develops -- if there's enough of a detour to go grab another town easily, if his line will be easy to upgrade, if he needs to buy different engines just to handle this one tricky stretch, etc. And basic stuff like how much he spent on it, and how efficiently the mountain line gets goods to and from each side of the hill.
--
Now, do I have a conclusion? Hmm. The lesson, if any, is "add minipuzzles." The tricky part is how. Sounds like a good future topic, eh? Part II in this series explores several good minipuzzles and examines what makes for a good minipuzzle. Part III, not yet written, will look at ways to add and improve minipuzzles.
Labels:
minipuzzles,
terminology
Tuesday, August 5, 2008
Time Sinks and Addiction
Can you be addicted to something that doesn't take much time, money, or energy?
I was thinking about games that pull me in and don't let go. They're addicting because they're demanding. Most games are very demanding; you're either playing or you aren't.
But there's a bunch of games that aren't as demanding -- browser games, play-by-mail games, play-by-email games, the turn-based games that were popular on BBSes back when that was cool, etc. You play once a day, or maybe more, but you're not stuck to the keyboard. I don't think these games are very addictive. You might wait expectantly for the next turn to show up in the mail, and maybe that's a bit addictive, but it's also easy to go a week without playing, or planning, or thinking about the game other than "I hope my turn shows up soon."
Except Travian has been like that for me. You don't need to be at the keyboard all day, but it helps. There are those that play "speed" servers like speed freaks, and have "sitters" (people on the other side of the globe) that play the game with them -- where each one of them plays the game for 12 hours a day.
You can play the game by stopping in once an hour, or every three hours. The game is like compounding interest, though. You collect more resources, which you use to make bigger fields or more combat troops, which then respectively either produce or steal more resources. Which you then re-invest in bigger fields or more combat troops.... The faster you re-invest, the greater the growth. If you delay in turning around those resources, you'll collect a certain percent less -- say, 10%. And just like compounding interest, over the course of a week that 10% turns into 100%. Week on week, it adds up to orders of magnitude.
For me there's this very real, mathematical incentive to re-deploy troops as soon as they come back. Why leave them sitting around when they could be out making money for you?
In some sense the game's a time sink. A more elegant troop-command interface would make sending out raids faster, especially when one is raiding the same targets over and over. A way to queue orders for, say, an entire day would mean you don't need to log in and check so often.
And yet the game isn't like that. I feel compelled to log in, in order to play "efficiently." I'm addicted; I need my quick little fixes, over and over. I keep coming back for more, obsessively pounding the lever and getting my food pellets in tiny doses.
A similar mechanism happens in "full-time" games, ie games where you generally stay logged in / connected / playing for longer sessions. Tetris has levels; Diablo has levels; World of Warcraft has character levels; Half-Life has levels; Guitar Hero has songs and venues and stars; Mario has stars and levels; etc etc. There's always "just one more" task, and it's small.
Sometimes the task is, well, kinda stupid. I'm sitting here thinking about how to spend less time mucking with Travian, because I'm obsessing over it at the moment. I was tempted to just delete the account, about an hour ago, and move on to the next game -- or get back to writing code. That's because there's not a lot of 'game' to Travian. It's a bit like Chess in that regard; the pieces move rather simply, but it's the complexity of human opponents that makes the game so rich. It's not a puzzle, nor a simple strength or skill test; there's a lot of strategy involved in doing well. (Strategy of the planning variety.)
Addictive games give out rewards frequently. When the player expects some new trinket in a short while, they'll keep playing, and then stay, expecting the next trinket. There's easily more complexity to add here -- such as adding high-level or bigger rewards every so often. And tons of other stuff. But the basic notion -- small rewards at frequent intervals -- is the heart of addiction. All the better if the game demands constant attention and rewards that attention.
I was thinking about games that pull me in and don't let go. They're addicting because they're demanding. Most games are very demanding; you're either playing or you aren't.
But there's a bunch of games that aren't as demanding -- browser games, play-by-mail games, play-by-email games, the turn-based games that were popular on BBSes back when that was cool, etc. You play once a day, or maybe more, but you're not stuck to the keyboard. I don't think these games are very addictive. You might wait expectantly for the next turn to show up in the mail, and maybe that's a bit addictive, but it's also easy to go a week without playing, or planning, or thinking about the game other than "I hope my turn shows up soon."
Except Travian has been like that for me. You don't need to be at the keyboard all day, but it helps. There are those that play "speed" servers like speed freaks, and have "sitters" (people on the other side of the globe) that play the game with them -- where each one of them plays the game for 12 hours a day.
You can play the game by stopping in once an hour, or every three hours. The game is like compounding interest, though. You collect more resources, which you use to make bigger fields or more combat troops, which then respectively either produce or steal more resources. Which you then re-invest in bigger fields or more combat troops.... The faster you re-invest, the greater the growth. If you delay in turning around those resources, you'll collect a certain percent less -- say, 10%. And just like compounding interest, over the course of a week that 10% turns into 100%. Week on week, it adds up to orders of magnitude.
For me there's this very real, mathematical incentive to re-deploy troops as soon as they come back. Why leave them sitting around when they could be out making money for you?
In some sense the game's a time sink. A more elegant troop-command interface would make sending out raids faster, especially when one is raiding the same targets over and over. A way to queue orders for, say, an entire day would mean you don't need to log in and check so often.
And yet the game isn't like that. I feel compelled to log in, in order to play "efficiently." I'm addicted; I need my quick little fixes, over and over. I keep coming back for more, obsessively pounding the lever and getting my food pellets in tiny doses.
A similar mechanism happens in "full-time" games, ie games where you generally stay logged in / connected / playing for longer sessions. Tetris has levels; Diablo has levels; World of Warcraft has character levels; Half-Life has levels; Guitar Hero has songs and venues and stars; Mario has stars and levels; etc etc. There's always "just one more" task, and it's small.
Sometimes the task is, well, kinda stupid. I'm sitting here thinking about how to spend less time mucking with Travian, because I'm obsessing over it at the moment. I was tempted to just delete the account, about an hour ago, and move on to the next game -- or get back to writing code. That's because there's not a lot of 'game' to Travian. It's a bit like Chess in that regard; the pieces move rather simply, but it's the complexity of human opponents that makes the game so rich. It's not a puzzle, nor a simple strength or skill test; there's a lot of strategy involved in doing well. (Strategy of the planning variety.)
Addictive games give out rewards frequently. When the player expects some new trinket in a short while, they'll keep playing, and then stay, expecting the next trinket. There's easily more complexity to add here -- such as adding high-level or bigger rewards every so often. And tons of other stuff. But the basic notion -- small rewards at frequent intervals -- is the heart of addiction. All the better if the game demands constant attention and rewards that attention.
Labels:
addiction,
wasting time
Saturday, August 2, 2008
Ownership, Aggregation, and Composition
Object Oriented Programming has a lot of associated jargon. You don't need to know the jargon to be a good architect, but understanding the concepts is important.
Short Form: composition is when class A owns an instance of class B; aggregation is when class A contains a pointer to class B (ie as a member variable), but doesn't own it. (Ownership implies that when the owner is destroyed, it will delete its ownees.)
Problem
There's lots of other sites that explain these things. Do they do a good job? I don't think so. I think most of them are targeted at either someone that knows nothing about OO, or someone that knows it fairly well but just wants a refresher. Like me. What's the difference between aggregation and composition again? Oh, composition is when you own the object, yeah, ok... If you aren't familiar with these concepts, then go read up on OO. I'm assuming that you've run across them before, and most likely distinguish between these two when you're writing code.
It's the sort of thing that's almost automatic, if you've learned to avoid pitfalls. Ownership is an important concept because of memory leaks. In C++, you've also got to be wary of dangling pointers and double-deletion. Back (in the olden days) when I was writing C++, I was always very careful to mark which class owned a given object.
In complex projects (especially games) you often have a ton of different objects which each have to reference the same thing. Bullets are fired by players, need to be drawn, create visual effects, collide with world geometry, etc. And in order to optimize several subsystems -- graphics and physics being two time-intensive subsystems -- you might have arcane container types. So how do you keep everything in order?
Solution
The answer is explicit ownership. Make it clear, to yourself and to whomever else is using the code. Put it in comments in the code, probably at the variable declaration and also in the header file for the contained class. If you scribble a diagram up on your whiteboard, make sure you're marking ownership clearly. Have only one owner.
Stay away from two owners. Good architectures would be having one clear owner, or having many owners -- like five, or twenty. In the latter case, you'd use reference counting or some other scheme to control deletion, such as using a globally-accessible (ie Singleton) container or manager or cache for those objects.
Sometimes the problem is something like this: bullets belong to players, but are aggregated within some class in the graphics system. But then a player logs out, the player object gets deleted, and now the graphics system has an empty pointer. Do you reference count this object? Do you keep the player object around (even after the player has logged) until all associated objects are deleted? This latter solution is why you often see players still in the game after their connection has died -- it's not so much an issue of the game not noticing the player has disconnected as the code doesn't want to delete the object yet.
Usually the cleanest solutions I've found to these my-two-dads sort of problems comes from thinking laterally. Do something completely different with bullets. Maybe a custom "reference count" used only by those two systems (although I think this is a hacky solution). Maybe bullets aren't owned by players at all, but contain a reference to a player ID allowing whatever system deals with the bullets to back-track to the player without having to worry about the player object still being around.
Jargon
The are two reasons to learn standard OO concepts. One is to help you become a better programmer. The other is so that you can communicate these concepts to other programmers. For any given concept that you learn, it's important to have a tag, a name, a label by which to refer to that concept. Having to say "that thing where you own this object that then has a pointer to a base class" is messy, when you could just say "bridge" -- which also captures a bit of intention, as well as architecture.
Say someone comes up to you and asks you what the difference between Aggregation and Containment is. Do you know? Can you explain it clearly? Probably only if you use those names a lot. I think ownership is an important concept and I use that word a lot in my code -- but I don't say // this object is aggregated or // contained. That would be lame.
I know the difference between the two. I don't think I'd be able to explain which one is which next week. Maybe, because I spent the time to write a post about it -- but that would be why, not because I use those words all the time. I think they're an awkward way to look at a more fundamental issue -- ownership.
Short Form: composition is when class A owns an instance of class B; aggregation is when class A contains a pointer to class B (ie as a member variable), but doesn't own it. (Ownership implies that when the owner is destroyed, it will delete its ownees.)
Problem
There's lots of other sites that explain these things. Do they do a good job? I don't think so. I think most of them are targeted at either someone that knows nothing about OO, or someone that knows it fairly well but just wants a refresher. Like me. What's the difference between aggregation and composition again? Oh, composition is when you own the object, yeah, ok... If you aren't familiar with these concepts, then go read up on OO. I'm assuming that you've run across them before, and most likely distinguish between these two when you're writing code.
It's the sort of thing that's almost automatic, if you've learned to avoid pitfalls. Ownership is an important concept because of memory leaks. In C++, you've also got to be wary of dangling pointers and double-deletion. Back (in the olden days) when I was writing C++, I was always very careful to mark which class owned a given object.
In complex projects (especially games) you often have a ton of different objects which each have to reference the same thing. Bullets are fired by players, need to be drawn, create visual effects, collide with world geometry, etc. And in order to optimize several subsystems -- graphics and physics being two time-intensive subsystems -- you might have arcane container types. So how do you keep everything in order?
Solution
The answer is explicit ownership. Make it clear, to yourself and to whomever else is using the code. Put it in comments in the code, probably at the variable declaration and also in the header file for the contained class. If you scribble a diagram up on your whiteboard, make sure you're marking ownership clearly. Have only one owner.
Stay away from two owners. Good architectures would be having one clear owner, or having many owners -- like five, or twenty. In the latter case, you'd use reference counting or some other scheme to control deletion, such as using a globally-accessible (ie Singleton) container or manager or cache for those objects.
Sometimes the problem is something like this: bullets belong to players, but are aggregated within some class in the graphics system. But then a player logs out, the player object gets deleted, and now the graphics system has an empty pointer. Do you reference count this object? Do you keep the player object around (even after the player has logged) until all associated objects are deleted? This latter solution is why you often see players still in the game after their connection has died -- it's not so much an issue of the game not noticing the player has disconnected as the code doesn't want to delete the object yet.
Usually the cleanest solutions I've found to these my-two-dads sort of problems comes from thinking laterally. Do something completely different with bullets. Maybe a custom "reference count" used only by those two systems (although I think this is a hacky solution). Maybe bullets aren't owned by players at all, but contain a reference to a player ID allowing whatever system deals with the bullets to back-track to the player without having to worry about the player object still being around.
Jargon
The are two reasons to learn standard OO concepts. One is to help you become a better programmer. The other is so that you can communicate these concepts to other programmers. For any given concept that you learn, it's important to have a tag, a name, a label by which to refer to that concept. Having to say "that thing where you own this object that then has a pointer to a base class" is messy, when you could just say "bridge" -- which also captures a bit of intention, as well as architecture.
Say someone comes up to you and asks you what the difference between Aggregation and Containment is. Do you know? Can you explain it clearly? Probably only if you use those names a lot. I think ownership is an important concept and I use that word a lot in my code -- but I don't say // this object is aggregated or // contained. That would be lame.
I know the difference between the two. I don't think I'd be able to explain which one is which next week. Maybe, because I spent the time to write a post about it -- but that would be why, not because I use those words all the time. I think they're an awkward way to look at a more fundamental issue -- ownership.
Friday, August 1, 2008
Status as a Game Mechanic
Note: I've been using "mechanic" to refer to what the game does "behind the scenes", and using "gameplay" to refer to what the player does with his time. However I'm used to using "game mechanic" and "core mechanic" to refer to what I'm now referring to as gameplay... I think I need to revise my nomenclature. (See my previous post on game design theory for some discussion on these terms.)
Definitions
Players give many reasons for playing games, but do you trust your players? Are they all sufficiently introspective and educated to understand their own motivations? They know if they enjoy something, but I'm talking about why they enjoy it. I'll go into my own theory of fun at some later point, but for now, let me say that one of the reasons that players enjoy games is the status that they can show off for their achievements.
I'm not talking about achievement directly. If happiness is the achievement of value, then a well-adjusted person is happy (and enjoys a game) when he achieves game goals that he values. But that's not status -- status is telling your buddy how you did in the game last night, or riding your new mount through a capital city in Warcraft.
The issue is a bit complicated becomes there's both showing others as well as knowing that you achieved that status item. The braggart doesn't care about getting a status item except to the extent that he can brag about it. The latter is like the guy I mentioned above, someone that has internalized the game goals as his own values and enjoys the status symbol as a record of achievement.
My point is that it doesn't matter why a given player wants a status item -- just that he does want it.
The lesson is obvious: put status items in your game.
Examples
Many games have implicit status items. In RPGs, it's your character's gear. This is one of the great driving forces in WoW: do you have your dungeon 3 set? A flying mount? An epic flyer? Tier 4? Tier 6? Legendaries? Status in MMOs also comes from the group you play with: has your guild cleared Kara, Gruul's, or Black Temple? How far are you through the Plateau? I'm calling these status items implicit because the only obvious score in the game is your level - and is the same for all players at max levels.
In platformers, progress through the game and the accumulation of collectibles and tokens are status indicators. The game tells you what the status items are, and how many you've gathered so far. Yet these items are intrinsic to gameplay; the game is essentially nothing but pushing your status up.
In multiplayer first-person shooters, your status is your standing on the leaderboard. There's not much else to the game other than that score. Single-player shooters might also have a leaderboard that's shared; XBox 360 games typically have a Live component that shows how you measure up against the playerbase. (Level-based shooters have implicit status measured as progress through the game.)
The 360 brings up another way of gaining status: achievement points. I was playing Guitar Hero with a friend last weekend and he was going for a bunch of easy achievement points to push his Gamer Score over the 20,000 mark. We were joking about the arbitrariness of the achievement, even while going for it.
That's the way the brain works
It's the way the brain works -- which is my message here. Even if you know you're shooting for an arbitrary or meaningless goal, you do it anyway. Some people gloat in their shiny new beemer or tier 4 set piece or gamer score, and for them status symbols are clear motivators. The rest of us kinda catch the same disease by association. We might not feel the need to tell everyone about our status, yet we seek it just the same.
It's the score, it's what you're supposed to do.
This ties in a bit with my previous discussions on open worlds. Be careful of removing any sort of status indicator, or your player might think he's stumbled on a toy and wonder what he's supposed to do with it. Obviously we don't want to play or design boring games that people feel stuck playing just because they're chasing some status symbol. However, if your game is good, that status symbol can show them the way.
Don't be afraid of character levels; players like them. Use them to point your players towards the fun stuff you put in the game.
Definitions
Players give many reasons for playing games, but do you trust your players? Are they all sufficiently introspective and educated to understand their own motivations? They know if they enjoy something, but I'm talking about why they enjoy it. I'll go into my own theory of fun at some later point, but for now, let me say that one of the reasons that players enjoy games is the status that they can show off for their achievements.
I'm not talking about achievement directly. If happiness is the achievement of value, then a well-adjusted person is happy (and enjoys a game) when he achieves game goals that he values. But that's not status -- status is telling your buddy how you did in the game last night, or riding your new mount through a capital city in Warcraft.
The issue is a bit complicated becomes there's both showing others as well as knowing that you achieved that status item. The braggart doesn't care about getting a status item except to the extent that he can brag about it. The latter is like the guy I mentioned above, someone that has internalized the game goals as his own values and enjoys the status symbol as a record of achievement.
My point is that it doesn't matter why a given player wants a status item -- just that he does want it.
The lesson is obvious: put status items in your game.
Examples
Many games have implicit status items. In RPGs, it's your character's gear. This is one of the great driving forces in WoW: do you have your dungeon 3 set? A flying mount? An epic flyer? Tier 4? Tier 6? Legendaries? Status in MMOs also comes from the group you play with: has your guild cleared Kara, Gruul's, or Black Temple? How far are you through the Plateau? I'm calling these status items implicit because the only obvious score in the game is your level - and is the same for all players at max levels.
In platformers, progress through the game and the accumulation of collectibles and tokens are status indicators. The game tells you what the status items are, and how many you've gathered so far. Yet these items are intrinsic to gameplay; the game is essentially nothing but pushing your status up.
In multiplayer first-person shooters, your status is your standing on the leaderboard. There's not much else to the game other than that score. Single-player shooters might also have a leaderboard that's shared; XBox 360 games typically have a Live component that shows how you measure up against the playerbase. (Level-based shooters have implicit status measured as progress through the game.)
The 360 brings up another way of gaining status: achievement points. I was playing Guitar Hero with a friend last weekend and he was going for a bunch of easy achievement points to push his Gamer Score over the 20,000 mark. We were joking about the arbitrariness of the achievement, even while going for it.
That's the way the brain works
It's the way the brain works -- which is my message here. Even if you know you're shooting for an arbitrary or meaningless goal, you do it anyway. Some people gloat in their shiny new beemer or tier 4 set piece or gamer score, and for them status symbols are clear motivators. The rest of us kinda catch the same disease by association. We might not feel the need to tell everyone about our status, yet we seek it just the same.
It's the score, it's what you're supposed to do.
This ties in a bit with my previous discussions on open worlds. Be careful of removing any sort of status indicator, or your player might think he's stumbled on a toy and wonder what he's supposed to do with it. Obviously we don't want to play or design boring games that people feel stuck playing just because they're chasing some status symbol. However, if your game is good, that status symbol can show them the way.
Don't be afraid of character levels; players like them. Use them to point your players towards the fun stuff you put in the game.
Labels:
game design,
status,
terminology
Subscribe to:
Posts (Atom)