So, as the title of the post indicates, I have no idea what to write for today's blog post, so this is going to be a more all over the place post instead of a structured one. This is the price that you all pay for my insistence on posting things weekly instead of when I have something interesting to write, and the price that I will pay in the years to come that this is on the internet for everyone to see.
There are several things I would like to write, but I haven't given them enough though to do a proper post. I've been thinking a lot about the old City of Heroes tutorial and about SSA 1, both in regards to how they went well and where things could have been done better. I've also (still) been playing a lot of Civilization V... for better or worse.
I've also been thinking a lot about MMO's in general, specifically the nature of content, story, systems, and community building. I look at my experience in playing SWTOR, which admittedly I stopped at around level 25 when I was getting bored, and Secret World, where I stopped after I finished the story. Then, I look back on my experience playing the original EverQuest and wonder what the difference there was. I was horrible at the original EverQuest. My highest level character was 22 on the race PvP server. However, I loved exploring in that game. All of the continents fascinated me, and my most memorable experiences were of me going to places I didn't belong, like bringing said level 22 character to the freaking moon to avoid people PvPing me, then getting hopeless lost in a level 30+ zone of tunnels, where said character died a grim, horrible death. I compare that to my experience in SWTOR, where I generally never felt like exploring, although I did really like the Imperial Agent's storyline; if I didn't have to play the other side quests, which felt like they were getting in the way, I would've continued... and I probably should pick it up one day, as Jeff Hamilton keeps telling me that isn't as much of a problem any more. However, the point to this long paragraph is that I've been wondering about that special formula of content, systems, and community. What are some ways of bringing all three together without it feeling forced? If you go too far in forcing it, then the game is group only and unfriendly to soloists just looking to hop in and play. If you go to far in not worrying about it, then the game is too solo friendly, a community doesn't get built, and people start to leave because they're playing single player games.
Lastly, I've been starting to get more focused on actually pushing forward the book I'm trying to write. One thing that I'm enjoying at the moment is figuring out how to make it balanced, as it is a book about super heroes. Something that always bugged me about super hero stories is how to make them dramatic or interesting when you have people that can't die because they can regen, can time travel, read minds, etc. It was my biggest beef with the show, Heroes, after season 1. It felt like they needed a game design to go in and nerf the hell out of Hiro's abilities, sort of how they did with Peter Petrelli in season 3. There's still a lot to write in the book, as I'm only two chapters in, but I'm excited to write a story in this world where no one's invulnerable, psychic, has time travel, or can regen. That premise alone has caused a lot of ideas to crop in my mind, ideas that I'm excited to write down and eventually put out into a story. Maybe if I'm actually focused, I'll finish the book and publish it this year! ... that would be nice.
Anyway. That's it. This has been the scattered around blog post which has had very little information about how to be a better anything. Sorry for anyone who was looking for that. See you all next week with a hopefully more informative post!
Monday, January 28, 2013
Monday, January 21, 2013
Civilization V and MMO's
"Man, Civilization V is an amazing game. I can't stop playing it."
"Welcome to 2010."
"Thanks, Matt."
This was a conversation I had the other day with Matt Miller. I recently picked up Civilization V during the Steam "give us all your money and we'll give you more games than you can imagine" Sale, and I'm absolutely loving it. Granted, I am incredibly late to the party (my next post will be about this cool game called Fallout: New Vegas. Has anyone heard ofi t?) of Civilization V, but I figured better late than never. However, playing Civilization V got me thinking about ways that the design of that game can be an example of how to improve designs in future MMO's. This is post is just completely theory, but it's something I love thinking about when picking up new games.
What I find so fascinating about Civilization V is the AI system of the other civilizations, specifically the way they react to both my actions and the actions of civilizations around them. It feels like I have control over the world, while also making the game feel different each time, something which could be credited towards having so many different world leaders (and my own desire to hit the random button on my own leader). It's one of those games where the story is being crafted around me based off of how the AI reacts to my actions; denouncing one civilization could cause another to get angry at me, or one to like me. However, that doesn't last for very long depending on how that AI works.
One quick story from my recent game as an example. I'm (attempting) to play a completely peaceful civilization who just trades and does culture. I'm fairly far from other cities due to luck of the draw. There is Japan, the Huns, and the Netherlands nearby. I became friends with Japan and the Netherlands, which created a makeshift alliance, as they also liked each other. However, none of them particularly cared for the Huns. Both went to war against the Huns at various points and asked me to join, but I declined without insulting them. Japan eventually triumphed over the Huns and took their land. A few turns later, the Netherlands came to me asking for help in a war against Japan. I refused, and now Japan and the Netherlands, once former allies tied to me, are now at war, presumably over the extra land that Japan has. In the meantime, I'm continuing to trade goods with them and convert them to my religion, while I sit back and watch the chaos unfold.
This example was one that really fascinated at me, as I did nothing but sit back and watch everything unfold around me, yet I was still able to participate in a way. This scenario wasn't a specific one set up by a game designer, but rather one of a myriad of possibilities created due to intelligent AI behavior that was set up, and it's this particular thing that I think can be helpful to MMO's. Someone wrote an article on gamasutra about it once, and I wish I could find it, but the long and short of it was that more games should have AI that have more diverse reactions to players and to other AI actions.
The original EverQuest is a great example - guards in Freeport would attack rats etc., but then if a Dark Elf, Troll, or Ogre player walked by, they would also attack them, unless they did something to build up their rank to walk by. This is a more mundane example, sure, but the interesting part here was that the opposing players could do something to change the way the AI looked at them.
I don't have a great example of how this could be used in modern MMO's, but it's something that I'm going to be thinking about going down the road. Perhaps it's not applicable to things like short story arcs, like the ones I did on City of Heroes. This could be something more tuned to overworld zone events, like the ones in Guild Wars 2, which I feel does a good job of putting a little of this into practice. It could also just be something that won't work in an MMO setting, period. However, for me, it's exciting to play a game and think to myself, "How can I use the design in this game to improve my own designs?". If that leads to nothing, then that's fine, but there's always a chance of learning something new in any game I play, even if it's something that feels like it has nothing to do with an MMO.
"Welcome to 2010."
"Thanks, Matt."
This was a conversation I had the other day with Matt Miller. I recently picked up Civilization V during the Steam "give us all your money and we'll give you more games than you can imagine" Sale, and I'm absolutely loving it. Granted, I am incredibly late to the party (my next post will be about this cool game called Fallout: New Vegas. Has anyone heard ofi t?) of Civilization V, but I figured better late than never. However, playing Civilization V got me thinking about ways that the design of that game can be an example of how to improve designs in future MMO's. This is post is just completely theory, but it's something I love thinking about when picking up new games.
What I find so fascinating about Civilization V is the AI system of the other civilizations, specifically the way they react to both my actions and the actions of civilizations around them. It feels like I have control over the world, while also making the game feel different each time, something which could be credited towards having so many different world leaders (and my own desire to hit the random button on my own leader). It's one of those games where the story is being crafted around me based off of how the AI reacts to my actions; denouncing one civilization could cause another to get angry at me, or one to like me. However, that doesn't last for very long depending on how that AI works.
One quick story from my recent game as an example. I'm (attempting) to play a completely peaceful civilization who just trades and does culture. I'm fairly far from other cities due to luck of the draw. There is Japan, the Huns, and the Netherlands nearby. I became friends with Japan and the Netherlands, which created a makeshift alliance, as they also liked each other. However, none of them particularly cared for the Huns. Both went to war against the Huns at various points and asked me to join, but I declined without insulting them. Japan eventually triumphed over the Huns and took their land. A few turns later, the Netherlands came to me asking for help in a war against Japan. I refused, and now Japan and the Netherlands, once former allies tied to me, are now at war, presumably over the extra land that Japan has. In the meantime, I'm continuing to trade goods with them and convert them to my religion, while I sit back and watch the chaos unfold.
This example was one that really fascinated at me, as I did nothing but sit back and watch everything unfold around me, yet I was still able to participate in a way. This scenario wasn't a specific one set up by a game designer, but rather one of a myriad of possibilities created due to intelligent AI behavior that was set up, and it's this particular thing that I think can be helpful to MMO's. Someone wrote an article on gamasutra about it once, and I wish I could find it, but the long and short of it was that more games should have AI that have more diverse reactions to players and to other AI actions.
The original EverQuest is a great example - guards in Freeport would attack rats etc., but then if a Dark Elf, Troll, or Ogre player walked by, they would also attack them, unless they did something to build up their rank to walk by. This is a more mundane example, sure, but the interesting part here was that the opposing players could do something to change the way the AI looked at them.
I don't have a great example of how this could be used in modern MMO's, but it's something that I'm going to be thinking about going down the road. Perhaps it's not applicable to things like short story arcs, like the ones I did on City of Heroes. This could be something more tuned to overworld zone events, like the ones in Guild Wars 2, which I feel does a good job of putting a little of this into practice. It could also just be something that won't work in an MMO setting, period. However, for me, it's exciting to play a game and think to myself, "How can I use the design in this game to improve my own designs?". If that leads to nothing, then that's fine, but there's always a chance of learning something new in any game I play, even if it's something that feels like it has nothing to do with an MMO.
Sunday, January 13, 2013
Quality Care for Quality Assurance
When I first started work at Paragon, Joe "Hero 1" Morrisey taught me a valuable lesson about people who worked in Quality Assurance, QA. He said that he has seen many people in the industry abuse people in QA and treat them as if they weren't human. Joe advised me to always treat people in QA with respect and dignity, and to always remember there's a person behind that bug report that I received. This is a lesson I've taken to heart, and something that I try to live through my design work.
A lot of stories from Penny Arcade's The Trenches shock me, wondering how anyone could treat people in QA like that. There is a tendency for people to view QA as a "lesser" role than that of design, art, or programming. This is something that I never understood, because when you really get down to the heart of it, the role of QA to is to make sure that you don't look like an idiot. I can safely say that much of my work that went live was only as good as it was because of people in QA running it and finding things that I never would have thought could go wrong, even if I did think very hard about it (and I did!). People in QA are the watchful guardians (queue Batman music) who make sure that the collaborative efforts of design, art, and programming all actually work through a myriad of test cases. If you ask me, this sounds like a pretty damn important task to me, which is why I try my best to always be respectful to QA.
I say try my best because sometimes as a designer, you can forget that, and here's why. Your work (and I speak for myself in this) is like your child. You're proud of it, you think it's great, it's the best kid in the class. The people in QA are the teachers who tell you that your kid isn't the A student you thought he was, that he's getting C's in Math and D's in English and that you really ought to see what's up with him crashing when he talks to people. In short, they're the ones telling you that you didn't do something right, and that can be aggravating or downright insulting to see someone telling you that you're not as good as you thought you were.
That being said, it's also something that, once you realize it, you can get over it and appreciate the feedback. It's great to get those bugs in from QA, because they're the ones who found it, not the players! A showstopper bug where you can't progress through a level is much better to find testing rather than in a live environment. If done right, you start to appreciate all the bugs of yours that QA finds, because it's another bug that didn't make it to live.
However, there are things that designers should do to help QA out to make their lives easier; if QA's lives are easier, it means more bugs are found, more feedback can be given, and the product as a whole comes out more polished. The first thing is to test your content before it goes to QA. Nothing is more wasteful than sending QA something you haven't tested and making them waste their time typing out bug reports for something that you could fix in two minutes. It's fine if you miss something while you're testing, everyone does, but if you just haven't plain walked through it, then you have no business sending it to anyone else.
Second, and this is more from a technical angle, provide QA with the tools to properly debug missions in a quick and efficient manner. This not only helps QA test things but also helps designers test their own work faster. On City of Heroes, I wanted to check for souvenir clues to see if a player did or didn't complete a story arc. The only tool we had at the time to grant a souvenir clue was to complete the final mission of the arc that gave it away, and to remove it you had to reset all of your mission info. In a nutshell, it was a giant pain. I talked with Tim "Black Scorpion" Sweeney about it, and he came up with two quick commands: scadd souvenir_name and scremove souvenir_name. Now, when I wanted to test things based off of souvenirs, it was a quick 10 second command that I or QA could run. As long as I put it in the outline of the mission, QA would have an easier time.
This leads me to my third point, which is writing mission outlines. If you want your mission to shine, then QA needs to understand how it's supposed work, inside and out. They should know all of the surprises, twists, and turns you put in there, so that way they can hammer on it and figure out all the ways it could go wrong. (Fun fact about City of Heroes: masterminds and stalkers broke EVERYTHING.) If your QA team is flying blind in your mission, then you can bet they're going to miss something, or that it's going to take them longer to figure out how things work. The longer QA takes to look at individual things, the higher your risk of something slipping through the cracks.
These are just some of the things I've learned and try to live by when interacting with folks in QA. Andy Maurer, a great programmer from Paragon, often said that being a good tester is a talent, one that's valuable, and I couldn't agree more. The ability for a person to think of a myriad of ways that something could go wrong and efficiently test it is a skill that I feel is not valued nearly enough in the games industry, as shown by the various tales from the Trenches. People in QA are there solely to help everyone in the team look better, and that's a fact. Every great game made has a great team behind it, and that doubly includes the QA department that more often than not gets blamed rather than praise, so take the time to appreciate them and give them the credit they deserve.
A lot of stories from Penny Arcade's The Trenches shock me, wondering how anyone could treat people in QA like that. There is a tendency for people to view QA as a "lesser" role than that of design, art, or programming. This is something that I never understood, because when you really get down to the heart of it, the role of QA to is to make sure that you don't look like an idiot. I can safely say that much of my work that went live was only as good as it was because of people in QA running it and finding things that I never would have thought could go wrong, even if I did think very hard about it (and I did!). People in QA are the watchful guardians (queue Batman music) who make sure that the collaborative efforts of design, art, and programming all actually work through a myriad of test cases. If you ask me, this sounds like a pretty damn important task to me, which is why I try my best to always be respectful to QA.
I say try my best because sometimes as a designer, you can forget that, and here's why. Your work (and I speak for myself in this) is like your child. You're proud of it, you think it's great, it's the best kid in the class. The people in QA are the teachers who tell you that your kid isn't the A student you thought he was, that he's getting C's in Math and D's in English and that you really ought to see what's up with him crashing when he talks to people. In short, they're the ones telling you that you didn't do something right, and that can be aggravating or downright insulting to see someone telling you that you're not as good as you thought you were.
That being said, it's also something that, once you realize it, you can get over it and appreciate the feedback. It's great to get those bugs in from QA, because they're the ones who found it, not the players! A showstopper bug where you can't progress through a level is much better to find testing rather than in a live environment. If done right, you start to appreciate all the bugs of yours that QA finds, because it's another bug that didn't make it to live.
However, there are things that designers should do to help QA out to make their lives easier; if QA's lives are easier, it means more bugs are found, more feedback can be given, and the product as a whole comes out more polished. The first thing is to test your content before it goes to QA. Nothing is more wasteful than sending QA something you haven't tested and making them waste their time typing out bug reports for something that you could fix in two minutes. It's fine if you miss something while you're testing, everyone does, but if you just haven't plain walked through it, then you have no business sending it to anyone else.
Second, and this is more from a technical angle, provide QA with the tools to properly debug missions in a quick and efficient manner. This not only helps QA test things but also helps designers test their own work faster. On City of Heroes, I wanted to check for souvenir clues to see if a player did or didn't complete a story arc. The only tool we had at the time to grant a souvenir clue was to complete the final mission of the arc that gave it away, and to remove it you had to reset all of your mission info. In a nutshell, it was a giant pain. I talked with Tim "Black Scorpion" Sweeney about it, and he came up with two quick commands: scadd souvenir_name and scremove souvenir_name. Now, when I wanted to test things based off of souvenirs, it was a quick 10 second command that I or QA could run. As long as I put it in the outline of the mission, QA would have an easier time.
This leads me to my third point, which is writing mission outlines. If you want your mission to shine, then QA needs to understand how it's supposed work, inside and out. They should know all of the surprises, twists, and turns you put in there, so that way they can hammer on it and figure out all the ways it could go wrong. (Fun fact about City of Heroes: masterminds and stalkers broke EVERYTHING.) If your QA team is flying blind in your mission, then you can bet they're going to miss something, or that it's going to take them longer to figure out how things work. The longer QA takes to look at individual things, the higher your risk of something slipping through the cracks.
These are just some of the things I've learned and try to live by when interacting with folks in QA. Andy Maurer, a great programmer from Paragon, often said that being a good tester is a talent, one that's valuable, and I couldn't agree more. The ability for a person to think of a myriad of ways that something could go wrong and efficiently test it is a skill that I feel is not valued nearly enough in the games industry, as shown by the various tales from the Trenches. People in QA are there solely to help everyone in the team look better, and that's a fact. Every great game made has a great team behind it, and that doubly includes the QA department that more often than not gets blamed rather than praise, so take the time to appreciate them and give them the credit they deserve.
Sunday, January 6, 2013
Tutorial Design Philosophies
Happy new year everyone! Apologies for the lack of posting, but I was on vacation, so, I didn't post. That's really all I have to say about it. Sorry!
Today, I'd like to talk briefly about some of my tutorial design theories. Back on City of Heroes, I designed the new tutorial for the free to play launch. I had also worked a bit on the Going Rogue tutorial. I realized now that MMO tutorials are starting to become one of my "things", so I'd like to sit back and analyze it a bit more. Tutorials honestly fascinate me, more than I thought they would - it's interesting to see the ideas people come up with to try to teach someone their game. I'll go into the details of the CoH tutorial in a later post regarding what went well, what could have been done better, etc., but today, I'll talk about the design philosophies I learned on City of Heroes for making tutorials.
First off, a tutorial for a free to play game is vastly different from a tutorial from a non-F2P game. The guys who make Uncharted aren't trying to convince you to buy the game through the tutorial, they're just there to help you understand the game. You've already bought the game, they already have your money. In contrast, a F2P tutorial is trying to both teach the player about the game and sell them on continuing to play the game; if it's boring, they'll leave, unless the person is really interested or already a fan of your game or genre. That's the rub, however, with a tutorial - how do you make it exciting, while also teaching the player what's going on?
One of the first steps is to not overload the player with too much work. It shouldn't be hard to explain to them the first steps of the game. While working on the CoH Freedom tutorial, I believed that a free player in the first 5 minutes has so little attachment to the game that they shouldn't be asked to do very much work to understand things. If you're not sure if you're interested in a subject, and then that subject asks you to do a lot of work, then chances are you're going to cut and run, as you have no attachment to urge you to do that work. As the player goes on, of course, they have more of an attachment to the game and can do a little more work to find out things: looking through menu's, waiting a few minutes for a queue to start for a team, etc. But the tutorial needs to be a well-oiled machine, where the player isn't asked to read a wall of text (like the one I'm writing now) or wait around for something to happen.
I sincerely believe one of the keys to this is to spread out what you teach in a tutorial. Many people have already said that if you're not going to use it in the next 3 minutes, don't teach it. As an example, the old City of Heroes tutorial explained how enhancements worked from the get go. However, you never needed to seriously use enhancements until level six, a full five levels afterwards, which, at that point, you've probably forgotten about what you learned in the tutorial. There was, in my opinion, no point in teaching that so early.
The main thing your initial tutorial has to do is arm the player with enough basic knowledge that they know how to play the game, that they feel free to do what they want in it. They should understand how to move, attack, talk, how do to quests, level up, and the location of their items, to name a few things (and I'm sure I've forgotten a few).
The rest of the details of the game can be spread out as the player goes along. The best way to do this, again in my opinion, is to let it meld with normal game play I personally hate it when I see "TUTORIAL: How to..." on a mission, because I'm not going to do it. I don't want to spend my time on the game doing what is essentially a class, I want to learn it as I'm going along in a story. A great example of this was the Montague Castanella arc in City of Heroes, where you're collecting salvage from the mission and have to use that to create an invention. Up to that point, I had no idea how the invention system worked. However, after doing that arc, it all clicked once I hit create invention. I realized all that salvage I had could be used for the exact same thing!
Finally, going back to the tutorial, it needs to be fun and a good representation of how your game is. It should also leave players wanting more and excited at the end of it. I think of it as the opening sequence of a movie, like the first Indiana Jones movie. The rolling boulder scene from the prologue is something I always remember, followed by Indie being chased by all the natives. It was something that, by the end, I was excited to see what would happen in the rest of the movie. I feel like a good tutorial should, at the end, have the player excited about the game and wanting to see more of it. The key then is to actually deliver, and that your tutorial isn't a bait and switch "haha no we actually don't do that". Which, sadly, for CoH, we didn't fight many giant monsters like the giant shivan.
As I've said in many of my other posts, these are just theories of mine that I'm constantly working on. Making a good tutorial takes a lot of skill and knowledge; making a good tutorial for a free to play game is even harder, in my opinion. I'm looking forward to playing more tutorials of more games, free to play and regular, to see the various ideas that people have thrown up, as if to say, "here's what I think a good tutorial is" and seeing what sticks and doesn't stick.
Today, I'd like to talk briefly about some of my tutorial design theories. Back on City of Heroes, I designed the new tutorial for the free to play launch. I had also worked a bit on the Going Rogue tutorial. I realized now that MMO tutorials are starting to become one of my "things", so I'd like to sit back and analyze it a bit more. Tutorials honestly fascinate me, more than I thought they would - it's interesting to see the ideas people come up with to try to teach someone their game. I'll go into the details of the CoH tutorial in a later post regarding what went well, what could have been done better, etc., but today, I'll talk about the design philosophies I learned on City of Heroes for making tutorials.
First off, a tutorial for a free to play game is vastly different from a tutorial from a non-F2P game. The guys who make Uncharted aren't trying to convince you to buy the game through the tutorial, they're just there to help you understand the game. You've already bought the game, they already have your money. In contrast, a F2P tutorial is trying to both teach the player about the game and sell them on continuing to play the game; if it's boring, they'll leave, unless the person is really interested or already a fan of your game or genre. That's the rub, however, with a tutorial - how do you make it exciting, while also teaching the player what's going on?
One of the first steps is to not overload the player with too much work. It shouldn't be hard to explain to them the first steps of the game. While working on the CoH Freedom tutorial, I believed that a free player in the first 5 minutes has so little attachment to the game that they shouldn't be asked to do very much work to understand things. If you're not sure if you're interested in a subject, and then that subject asks you to do a lot of work, then chances are you're going to cut and run, as you have no attachment to urge you to do that work. As the player goes on, of course, they have more of an attachment to the game and can do a little more work to find out things: looking through menu's, waiting a few minutes for a queue to start for a team, etc. But the tutorial needs to be a well-oiled machine, where the player isn't asked to read a wall of text (like the one I'm writing now) or wait around for something to happen.
I sincerely believe one of the keys to this is to spread out what you teach in a tutorial. Many people have already said that if you're not going to use it in the next 3 minutes, don't teach it. As an example, the old City of Heroes tutorial explained how enhancements worked from the get go. However, you never needed to seriously use enhancements until level six, a full five levels afterwards, which, at that point, you've probably forgotten about what you learned in the tutorial. There was, in my opinion, no point in teaching that so early.
The main thing your initial tutorial has to do is arm the player with enough basic knowledge that they know how to play the game, that they feel free to do what they want in it. They should understand how to move, attack, talk, how do to quests, level up, and the location of their items, to name a few things (and I'm sure I've forgotten a few).
The rest of the details of the game can be spread out as the player goes along. The best way to do this, again in my opinion, is to let it meld with normal game play I personally hate it when I see "TUTORIAL: How to..." on a mission, because I'm not going to do it. I don't want to spend my time on the game doing what is essentially a class, I want to learn it as I'm going along in a story. A great example of this was the Montague Castanella arc in City of Heroes, where you're collecting salvage from the mission and have to use that to create an invention. Up to that point, I had no idea how the invention system worked. However, after doing that arc, it all clicked once I hit create invention. I realized all that salvage I had could be used for the exact same thing!
Finally, going back to the tutorial, it needs to be fun and a good representation of how your game is. It should also leave players wanting more and excited at the end of it. I think of it as the opening sequence of a movie, like the first Indiana Jones movie. The rolling boulder scene from the prologue is something I always remember, followed by Indie being chased by all the natives. It was something that, by the end, I was excited to see what would happen in the rest of the movie. I feel like a good tutorial should, at the end, have the player excited about the game and wanting to see more of it. The key then is to actually deliver, and that your tutorial isn't a bait and switch "haha no we actually don't do that". Which, sadly, for CoH, we didn't fight many giant monsters like the giant shivan.
As I've said in many of my other posts, these are just theories of mine that I'm constantly working on. Making a good tutorial takes a lot of skill and knowledge; making a good tutorial for a free to play game is even harder, in my opinion. I'm looking forward to playing more tutorials of more games, free to play and regular, to see the various ideas that people have thrown up, as if to say, "here's what I think a good tutorial is" and seeing what sticks and doesn't stick.
Subscribe to:
Posts (Atom)