Our readings for today covers a substantial amount of material in game mechanics and game balancing. We can easily view the readings as continuous and building on the same umbrella topic. Game mechanics are the fundamentals blocks of games, they are what determines the basic functions and feel of the game. Game balancing, on the other hand, is the fine-tuning of pre-existing mechanics to maximize player enjoyment.
Adams breaks game mechanics into 6 aspects. 4 of them are: Space, Objects/Attributes/States, Actions and Rules. The other two were mysteriously not included in our provided readings.
In terms of game balancing, Adams immediately sets the precedent that there are differences between balancing for PvE (player versus environment) and PvP (player versus player) games. One of the recurring themes throughout the article is avoiding dominant strategies--strategies which trump most other tactics. The point to game balancing is to create a system where no specific strategy or style/race/class is more powerful than the other. He says that balanced games seldom result in stalemates, are perceived to be fair, are forgiving to those who fall behind early on, provide meaningful choices, and does not let chance make skill irrelevant.
Later, Adams goes into difficulty types. It seems as though he favors the idea of dynamic difficulty adjustments; games which adjust their difficulty depending upon player skill. This makes sense because it naturally fits itself to make the most comfortable experience for whoever is playing. By riding the line of "just challenging enough", video games will be able to engage their players in that spot of flow for a much more effective amount of time than rigid, static difficulty levels (which can frustrate players).
Tuesday, October 9, 2012
Friday, October 5, 2012
Dead State Design Discussions
It goes without saying that everyone in this class loves games. As I've stated before, I am particularly fond of zombie games. This led me to backing a project on Kickstarter called Dead State: The Zombie Survival RPG by DoubleBear Productions (http://www.kickstarter.com/projects/70755535/dead-state-the-zombie-survival-rpg). I won't go into all of the details, but I really love these sort of games.
Anywho, for those who don't know, Kickstarter is a crowdfunding platform where creators post projects and seek funding from others. They set a fundraising goal and if they reach it, the project is backed and the creators receive money for everyone who pledged money towards the project; if the project doesn't meet their goal, then the creators receive nothing. In other words, it's an all-or-nothing system.
I digress. Once you back a project, you become eligible to receive backer-only updates--information that is only given those who have supported the project.
You know, I'm explaining all of this and I bet y'all already know it, right? I'll shut up about it now.
I just received this backer-only update from the project and I thought that their discussion on NPC ally creation and dialogue writing is something worth noting for this class.
Here it is!
![]()
Design continues to work primarily on dialogue. As stated before, there is not only a lot of dialogue, but complex dialogue that spans great lengths of time and decisions rather than the length of completing a quest. I thought it might be interesting to shed some light on our ally creation and dialogue writing process. It starts with Annie and I discussing concepts for characters in the shelter. Usually, everyone we add needs to create a potential conflict or interaction with one or more other characters in the shelter, plus bring a set of skills and personality traits that are not duplicated by another member of the group. We usually try to figure out if the character is going to be more useful in combat or out of combat, or if they unlock some other potential aspect of the shelter, like a new type of job or a prized skill (like a doctor). We also try to figure out if the character is traveling alone or with others – if they’re traveling with someone, it instantly creates an interesting narrative point, but that bond needs to be reinforced throughout the dialogue and even in the gameplay.
After we’ve come up with the basics of the character, we put together a bio for the character. We use backstory for writing purposes only, to give us a more fully-fleshed out character whose life did not begin when the player met them. While you’ll never see the backstories we create, elements of their lives will creep into their dialogue, and an attentive/inquisitive player will learn a lot more about their allies over time. Sometimes you may not know about certain aspects of the character unless a certain path is triggered, like watching them die from infection or gaining enough trust from a friend of theirs. However, like in real life, you will never fully understand everything there is to know about an ally (unless you’re one of the writers).
We translate their former profession and hobbies into stats and skills. Someone who was a park ranger might have a high survival skill because they can identify plants and a higher vigor because of time spent walking trails. They may have a perk for traveling faster on the area map because they know how to lead people through difficult terrain. These are gameplay skills that may make an ally more appealing if their character’s dialogue makes them seem difficult or combative with other allies. We balance gameplay advantages and personality flaws for every character you can add in the shelter.
Before writing the character, a list of every interaction possible with the player or other allies is made. This outline is used as a guide to track all the events we need to write. If we feel there’s a lack of interesting dramatic points or decisions, we will add them at this stage or while writing. We also simplify any chains of events that seem too complex or frustrating for a player to figure out. Some adjustment may be made to pace a character’s arc out over time to make sure they continue to pop up in the story. Additionally, we figure out any random events this character might be associated with and questions that the player may want to ask them (including dialogue for resolving personal requests).
From here, it’s all dialogue writing, which can introduce even more nuances and character developments that can only come out as we are subjecting ourselves to that character’s point of view. And now you understand a bit more about the dialogue process. We’re hoping the extra effort provides an experience that you won’t find anywhere else.
That’s it for this update. Remember, you can always interact with us on the forums if you’ve got questions. If you have received a survey (anyone $21 tier and up did) and still haven’t returned it, please do. For those with Radio access, expect another update very soon. As always, thank you all for making this possible.
Anywho, for those who don't know, Kickstarter is a crowdfunding platform where creators post projects and seek funding from others. They set a fundraising goal and if they reach it, the project is backed and the creators receive money for everyone who pledged money towards the project; if the project doesn't meet their goal, then the creators receive nothing. In other words, it's an all-or-nothing system.
I digress. Once you back a project, you become eligible to receive backer-only updates--information that is only given those who have supported the project.
You know, I'm explaining all of this and I bet y'all already know it, right? I'll shut up about it now.
I just received this backer-only update from the project and I thought that their discussion on NPC ally creation and dialogue writing is something worth noting for this class.
Here it is!
It’s October, which marks the beginning of our third month since Dead State’s Kickstarter was successfully funded. Our team continues to turn out new content, GUIs, animations, and gameplay code. We’ve made significant improvements to the Shelter, including finishing all the upgrades, giving the constructed areas a “scavenged materials look”, and finishing off the basement and second level. Additionally, I’d like to present this image:
What you’re looking at may not be a “pretty” area, but it’s pretty exciting to us. That’s the starting area of the game right there. Your decisions are yet to be made, your map is blank, your allies are all still alive, and your enemies and the undead are lurking out there – this is the moment where your story begins. We’re pretty excited about this image, just because we know what’s in store for you. It’s that moment in every game where you don’t know what to expect yet, where you can’t wait to get out and experience everything. (“Experiences” that we’re working on right now.)
Design continues to work primarily on dialogue. As stated before, there is not only a lot of dialogue, but complex dialogue that spans great lengths of time and decisions rather than the length of completing a quest. I thought it might be interesting to shed some light on our ally creation and dialogue writing process. It starts with Annie and I discussing concepts for characters in the shelter. Usually, everyone we add needs to create a potential conflict or interaction with one or more other characters in the shelter, plus bring a set of skills and personality traits that are not duplicated by another member of the group. We usually try to figure out if the character is going to be more useful in combat or out of combat, or if they unlock some other potential aspect of the shelter, like a new type of job or a prized skill (like a doctor). We also try to figure out if the character is traveling alone or with others – if they’re traveling with someone, it instantly creates an interesting narrative point, but that bond needs to be reinforced throughout the dialogue and even in the gameplay.
After we’ve come up with the basics of the character, we put together a bio for the character. We use backstory for writing purposes only, to give us a more fully-fleshed out character whose life did not begin when the player met them. While you’ll never see the backstories we create, elements of their lives will creep into their dialogue, and an attentive/inquisitive player will learn a lot more about their allies over time. Sometimes you may not know about certain aspects of the character unless a certain path is triggered, like watching them die from infection or gaining enough trust from a friend of theirs. However, like in real life, you will never fully understand everything there is to know about an ally (unless you’re one of the writers).
We translate their former profession and hobbies into stats and skills. Someone who was a park ranger might have a high survival skill because they can identify plants and a higher vigor because of time spent walking trails. They may have a perk for traveling faster on the area map because they know how to lead people through difficult terrain. These are gameplay skills that may make an ally more appealing if their character’s dialogue makes them seem difficult or combative with other allies. We balance gameplay advantages and personality flaws for every character you can add in the shelter.
Before writing the character, a list of every interaction possible with the player or other allies is made. This outline is used as a guide to track all the events we need to write. If we feel there’s a lack of interesting dramatic points or decisions, we will add them at this stage or while writing. We also simplify any chains of events that seem too complex or frustrating for a player to figure out. Some adjustment may be made to pace a character’s arc out over time to make sure they continue to pop up in the story. Additionally, we figure out any random events this character might be associated with and questions that the player may want to ask them (including dialogue for resolving personal requests).
From here, it’s all dialogue writing, which can introduce even more nuances and character developments that can only come out as we are subjecting ourselves to that character’s point of view. And now you understand a bit more about the dialogue process. We’re hoping the extra effort provides an experience that you won’t find anywhere else.
That’s it for this update. Remember, you can always interact with us on the forums if you’ve got questions. If you have received a survey (anyone $21 tier and up did) and still haven’t returned it, please do. For those with Radio access, expect another update very soon. As always, thank you all for making this possible.
Thursday, October 4, 2012
WoW as a means to earn campaign funds?
An interesting piece about credibility and gaming...http://m.nbcnews.com/technology/ingame/republicans-out-democrat-world-warcraft-witch-hunt-6283586
Crawford reading response
Between chapter five (the game design sequence) and chapter six (design techniques and ideals) there's a lot of information to think about, but what stood out the most to me was the bit on choosing a goal and topic.
According to Crawford, "the goal must be expressed in terms of the effect that it will have on the player". I think this is a very good approach. In fact, for our next project I've been struggling to come up with an idea because so far, I've just been trying to think of what kind of game I would want to make (shooter, rpg, etc.) but maybe I'll have better success/ideas if I instead choose a goal/lesson/personal aesthetic that I would want the game to have, and go from there.
I think it's really important to have a clear goal/topic for the game because it's the foundation or the guidelines that you can always refer back to because as you create/outline a game in detail you're probably going to start changing and wandering away from the original idea, so the more defined/specific/clear it is, the better (and personally successful) the game will be in the end.
According to Crawford, "the goal must be expressed in terms of the effect that it will have on the player". I think this is a very good approach. In fact, for our next project I've been struggling to come up with an idea because so far, I've just been trying to think of what kind of game I would want to make (shooter, rpg, etc.) but maybe I'll have better success/ideas if I instead choose a goal/lesson/personal aesthetic that I would want the game to have, and go from there.
I think it's really important to have a clear goal/topic for the game because it's the foundation or the guidelines that you can always refer back to because as you create/outline a game in detail you're probably going to start changing and wandering away from the original idea, so the more defined/specific/clear it is, the better (and personally successful) the game will be in the end.
Crawford Response
The first chapter we were supposed to read goes over the steps a designer can take to design a game. Some are obvious, such as the programming phase and the design phase, but there were also steps I had not thought about. I really hadn't put a lot of thought into researching a game, but I guess all games do need some level of research. Also, everything he had to say about setting the goal of a game was very interesting. It really does help a game have a purpose for being there and helping a gamer feel like they accomplished something after they play it. It also looks like it will help ground the designers as they work on other phases. And just because the programming phase and design phase were expected in the sequence did not mean they did not prove insightful. I had never thought of something like I/O sequences but I can see why they were very important to design around.
The second part of the reading talked about different techniques to keep in mind when designing a game. It felt like a much more dense read. The section about pitting the human against machine was interesting. After all, that is what a lot of games are all about; the only thing you are trying to defeat is the computer. It made me think of solitaire - the title of the section - but also all those chess and checker games that I played against the computer when I was younger. But you don't really want your player thinking that way; that it's being outwitted by it's smartphone. The different relationships the players could have with each other was also interesting. It made me think of the recent League of Legends games I played, or the last time I played Mario Kart. You need to make sure your players are balanced, but how do you balance humans?
The second part of the reading talked about different techniques to keep in mind when designing a game. It felt like a much more dense read. The section about pitting the human against machine was interesting. After all, that is what a lot of games are all about; the only thing you are trying to defeat is the computer. It made me think of solitaire - the title of the section - but also all those chess and checker games that I played against the computer when I was younger. But you don't really want your player thinking that way; that it's being outwitted by it's smartphone. The different relationships the players could have with each other was also interesting. It made me think of the recent League of Legends games I played, or the last time I played Mario Kart. You need to make sure your players are balanced, but how do you balance humans?
Tuesday, October 2, 2012
Graner Ray
The concept of a design document is the overall summary of how the game will be received by a standard three groups of demographic/outputs. It becomes a point of reference, something that holds the truth among the rumor, something serving the even opening audience. After the three basic overviews, chosen by Ray, the overall feel and expectations from the game can be anticipated. This can be summed up in the selling point; what is the concept of the game?
The first overview of product and introduction covers many of the first witnessing accounts of the game. The back of the package summary, overall cover art, the objective, genre, and role play are the first reviews a player will give the game before purchasing.
The second overview, sample game play, is the first hands on encounter with the game mechanics itself. Within the first 30 minutes, the player will soak in enough understanding of the context and purpose of the game to become either engaged or turned off.
Lastly, the technical overview will anticipate how well the game can be utilized on multiple consoles or with other gaming devices. The more universal the game can be used and the more flexible the design, the more sales the designers can expect. This limitation is not only from physical mechanics, but can also be derived from the game's properties themselves such as visual graphics, number of allowed moves, and overall experience.
The design document sounds like a general analysis of the game's affect on the market based on usability and whether it meets expectations.
The first overview of product and introduction covers many of the first witnessing accounts of the game. The back of the package summary, overall cover art, the objective, genre, and role play are the first reviews a player will give the game before purchasing.
The second overview, sample game play, is the first hands on encounter with the game mechanics itself. Within the first 30 minutes, the player will soak in enough understanding of the context and purpose of the game to become either engaged or turned off.
Lastly, the technical overview will anticipate how well the game can be utilized on multiple consoles or with other gaming devices. The more universal the game can be used and the more flexible the design, the more sales the designers can expect. This limitation is not only from physical mechanics, but can also be derived from the game's properties themselves such as visual graphics, number of allowed moves, and overall experience.
The design document sounds like a general analysis of the game's affect on the market based on usability and whether it meets expectations.
Rule Discussion
·
The information must be split up and not be
given all at once
·
Information should be sorted into categories
·
Information should be interactive
·
Information should not just be abstract theory.
Add examples of games that use these rules/theories
·
Use hyperlinks
We all agree that the information needs to be broken up and
not presented all at once. Our ideas revolve around taking the information and
sorting it into categories. The categories would not only have information but
examples of games that use this information. Then we connect these categories –
like hyperlinks in wiki articles. Then we would present this information in a
sort of dichotomous key. We would start by asking the person what kind of
information they are looking for – player info,
graphics, content, etc – and after a series of questions come up with a
list of categories the person would be interested in.
Subscribe to:
Posts (Atom)