Social status is an interesting issue in many U.S. combat larps. Some game systems leave it up to the players to write their status into the character backstory. Some have elaborate game mechanics which allow the purchase of status with experience. But lots of games have no official way to limit players from claiming any title they want (however silly that title may be). Many players abuse this and tell extremely similar stories. Games overflow with 'Counts', 'Dukes', and the brothers, nephews and sons of titled nobility who come complete with some kind of tragic backstory.
Many players also tend to ignore the interesting down to earth stories, and instead shoot straight for the Eurocentric Feudal landed caste. Occasionally players choose an Asian style Feudal landed caste to spice things up. This similarity of story is frustrating, limiting, and not all that fun. I've attempted to address this lack of depth with a character creation system based on group dynamics. It can generate nobility, but far more often produces 'salt of the earth' type folks. Today let's address the game mechanics of a social system.
A blog about writing combat Larp and how to be a better larper. Writing The Hit Location Handbook and prototyping a 4x style larp.
Showing posts with label theory. Show all posts
Showing posts with label theory. Show all posts
Friday, December 5, 2014
Monday, December 10, 2012
Metrics Driven Game Design
Zynga has defended the idea that designing a game heavily based on metrics input is a winning strategy. Although no one likes the idea of what the output is after that process. The popular trope around the indie game world is a general feeling of distaste for the kind of game that gets produced by putting in more numbers based feedback rather than human based feedback.
Wednesday, December 5, 2012
Ichiro Abroad
If you haven't had a chance to yet, pop over to this Gamasutra article and give it a read. Some really great basic advice, subtle yet powerful. Short post today due to high call volume in the call center. The new full time gig is taking up a lot of time, and there may be a big announcement coming soon, which will take up all the rest of the time. Also, if you just love Ichiro, here is his advice on going to GDC... Even if you just go to the vicinity of GDC it might be worth it.
Friday, November 16, 2012
What is the value of a good story?
What makes the D&D brand compelling? What makes it valuable? The game is valuable because it is a system of creating emotional meaning to the players (players find it fun and enjoy playing). The best DM’s are those who can invest meaning in the worlds they create and then use that meaning to emotionally affect the players. Likewise the best games are those that can invoke an emotional response. The best way to do that is to create a meaningful game world. How much is a good story worth in game design?
Friday, August 26, 2011
Razer Blade: Disruptive Technology that has missed the mark.
Razer released a full page Wall Street Journal ad telling us all the obvious. PC Gaming is not dead. Thanks. Mojang and I agree with you Razer. They made that claim as a teaser for the release of the Blade. A very thin, very portable gaming laptop. They must not have done much market research as they touted it as "the world's first true gaming laptop." Or perhaps they just don't feel that Alienware machines are up to par.
Tuesday, July 19, 2011
The Adwords Experiment
Google was nice enough to send me a free $100 gift card for Adwords. For anyone unfamiliar Adwords is the tool that lets you place ads in Googles search results. You create an ad, and then bid on keywords. The amount of competition, and your bid, determines if Google users see your ad or not. For some keywords the competition can be fierce. They keywords for most game related projects, however, remain very low in competition.
This 'windfall' represents the total marketing budget of The ZoRTS Project. Instead of advertising a game which doesn't exist yet it seemed like a better idea to get the word out about this blog. The real goal is building a community of folks who can tell me when I'm saying something stupid (always appreciated) about game design. This way the project benefits from more knowledge then I currently posses. Also learning how Adwords works should be a marketable skill in this day and age, right?
This 'windfall' represents the total marketing budget of The ZoRTS Project. Instead of advertising a game which doesn't exist yet it seemed like a better idea to get the word out about this blog. The real goal is building a community of folks who can tell me when I'm saying something stupid (always appreciated) about game design. This way the project benefits from more knowledge then I currently posses. Also learning how Adwords works should be a marketable skill in this day and age, right?
Upon getting the gift card my first step was to contact thetrafficblogger and asked his advice. He is my go to guy for all things blogging and social media related. His suggestion was to start a campaign with as many keywords as possible, that have low competition, and start by bidding $.01 on clicks. Thus began 'The Adwords Experiment'.
The Goal: Get 10,000 hits using $100
Whoa!?! That is a lot of hits, where did that number come from? That goal came from TheTrafficBlogger himself. Maybe he tossed it out randomly. Or maybe from the point of view of a professional blogger that should be a reasonable number, he must get 10,000 hits a post... But for a newbie like me? It is quite the challenge. But why not a randomly chosen big goal? Right. Jump in feet first!
The Method:
Week 1: One cent per click. Started July 14th to July 21st
Week 2: Two cents per click. July 22nd to July 28th
Week 3: Three center per click. July 29th to Aug 4th
Week 4: Four cents per click. Aug 5th to Aug 11th
Now I will also be spreading the word about blog.zorts.net in other ways at the same time. This behavior would loose points in the scientific world. But as this is a completely new blog, its fair to allow for other traffic sources. At the moment Reddit is my biggest source of traffic. There could be some expansion from Empire Avenue readers. It will also be very easy to figure out which hits came from where. So the analysis can include both with Reddit, and without.
First Hypothisis:
There is some cheap 'magic number' that will get me enough hits to break even between Adwords and Adsense.
Second Hypothisis:
There is some even more magic number which will net me a little profit for my trouble.
The Conclusion:
10,000 hits using only $100? That is definitely a challenge. We shall see if the final tally comes anywhere close. Before collecting the data, I have no idea what to expect. But imagine if that could be done! Regardless of how the experiment goes over all, I'm sure this is a valuable learning experience.
There is a post qued up for tommorrow with some general thoughts and a couple things noticed about Adwords. Expect additional posts as more is learned about Adwords. Keep checking back for updates on the experiments progress. Each week will get recapped on a Tuesday as an additional blog post! As always ask questions if there is something that hasn't been explained well. Those kinds of questions really help me curate the blog, and help make sure the blog posts make sense as well as provide valuable information. If you can think of anything that should be added to the experiment, comment below.
Friday, July 15, 2011
Game idea != Product
Scott McMillian, formerly head of MacGuffin Games, gave another great presentation at Boston Post Mortem Wednesday night. It was a second showing of "Death of an Indie Studio", a post mortem discussion the rise and fall of his own small business. There should be audio and perhaps video of the entire presentation coming along soon. Which will be really valuable to get the nuance of some of his statements (the art and business continuum, for example). For now you can find my notes and links to the slides. The official post from Boston Post Mortem is now up, with more visual goodness!
Monday, June 27, 2011
Cheap game design
Hypothetically lets assume you're a gamer with an idea for a game. This should be easy to imagine. You want to make a game but have no money. Once you have chosen your team, and gotten some idea of what you are building (with a game design document), and picked your distribution/coding platform, you realize that you need to keep track of a lot of different kinds of information. Specifically bug and issue tracking.
There are many great services out there with the ability to track issues, but there is another method which is often overlooked. You can build your own bug tracker using sites.google.com. As we were starting the ZoRTS project the Lead Coder asked me to find bug tracker to use. As a manager on a project with no money something with low cost is ideal. The following video on youtube provided the answer.
Pros:
There are a couple factors left out of the pros and cons. For example using sites.google.com as your issue tracker takes effort to build and maintain. You have to have and idea of what kinds of things you need to track ahead of time, and how the page is going to be used. The ZoRTS website includes an example page so that you can get an idea of the kinds of columns that you might need. However this is a moot point as you still need to spend time and effort updating and recording in any bug tracker. It might just take a minute or two more to use google sites.
So what do you use to provide an infrastructure for communication of issues, bugs, design changes? Why do you like to work with it? If you have experience in the area please leave a comment below, let us know your opinion.
There are many great services out there with the ability to track issues, but there is another method which is often overlooked. You can build your own bug tracker using sites.google.com. As we were starting the ZoRTS project the Lead Coder asked me to find bug tracker to use. As a manager on a project with no money something with low cost is ideal. The following video on youtube provided the answer.
Pros:
- Works with other Google services
- Cheap! As in free.
- Hand built to do exactly what you need it to do.
- There are other methods which may be better
There are a couple factors left out of the pros and cons. For example using sites.google.com as your issue tracker takes effort to build and maintain. You have to have and idea of what kinds of things you need to track ahead of time, and how the page is going to be used. The ZoRTS website includes an example page so that you can get an idea of the kinds of columns that you might need. However this is a moot point as you still need to spend time and effort updating and recording in any bug tracker. It might just take a minute or two more to use google sites.
So what do you use to provide an infrastructure for communication of issues, bugs, design changes? Why do you like to work with it? If you have experience in the area please leave a comment below, let us know your opinion.
Friday, May 27, 2011
Woot! Ars Technica, FTW.
Thanks Ars Technica, I was looking for charts and information about overworking employees. Great article today* from AT about overtime and crunch time. With links to research that was pioneered by Henry Fords company around the 1900's. Which makes it both impossible to read and some of the oldest scientific research we have about work. Be warned, it does not read well for those not versed in scientific research or 1900 speak.
TL;DR:
Comment below if you feel this is interesting or stupid. Also let me know if you are interested in research posts. Highly technical posts might not be terribly interesting.
*[Blog posts are written in advance, their post appeared about four days before the date this post went live.]
TL;DR:
- The 40 hour work week is an intentional construct based on research into human productivity.
- Overtime gives you a temporary boost in productivity, when used sparingly.
- Prolonged overtime drives productivity DOWN.
- Humans will voluntarily overwork themselves even when its not good for the project because they want the money.
Comment below if you feel this is interesting or stupid. Also let me know if you are interested in research posts. Highly technical posts might not be terribly interesting.
*[Blog posts are written in advance, their post appeared about four days before the date this post went live.]
Monday, May 16, 2011
Basic Project Management is important.
Although failure is always an option, and something we should learn from, what are some things that we can do to reduce failure? Two tips tied together into one: Deadlines and Feedback.
Not everyone has taken on Project Management as a studied discipline which is unfortunate as some of the tactics a project manager will use can be really handy when making a computer game. Any good business college will have you take at least one class in PM, and you might walk out of it with a PMBOK (Project Managers Body of Knowledge). As an Amateur Computer Game Designer you most likely will not need every piece of information in the PMBOK, but you can still benefit from a couple points that project managers are fond of. They also happen to be popular advice among Indie game developers.
During his talk at PAX Scott MacMillan stated that Deadlines are very important. It was something that he learned the hard way. You can see his slides from that presentation, but you cannot see what he discusses during those slides. It's something that I have also been learning about on the ZoRTS Project. Let me synthesize what has been learned first hand, what Scott was trying to say in his presentation, and a couple things picked up from Boston University.
Deadlines should be small tasks which can be completed regularly. There is an art to setting deadlines (with deliverables) in that they should not be made too big, nor too small. For example, here is a little list of things that could be deadlines for a computer game project.
These are some of the major components when building a computer game. You have to produce the engine that runs the game. Someone has to produce the visual and the auditory art and someone has to write text (could be in the game, could be website material). What is wrong with this list of deadlines? They have no specificity to them, and no deliverables. Which means it will be harder to determine if progress is being made within the project (no feedback).
Instead lets try goals which are tied directly to a deliverable and have much shorter durations. The actual times, deliverables and goals are going to be based on your project, theses are just used as an example, they are not specific suggestions.
Not everyone has taken on Project Management as a studied discipline which is unfortunate as some of the tactics a project manager will use can be really handy when making a computer game. Any good business college will have you take at least one class in PM, and you might walk out of it with a PMBOK (Project Managers Body of Knowledge). As an Amateur Computer Game Designer you most likely will not need every piece of information in the PMBOK, but you can still benefit from a couple points that project managers are fond of. They also happen to be popular advice among Indie game developers.
During his talk at PAX Scott MacMillan stated that Deadlines are very important. It was something that he learned the hard way. You can see his slides from that presentation, but you cannot see what he discusses during those slides. It's something that I have also been learning about on the ZoRTS Project. Let me synthesize what has been learned first hand, what Scott was trying to say in his presentation, and a couple things picked up from Boston University.
Deadlines should be small tasks which can be completed regularly. There is an art to setting deadlines (with deliverables) in that they should not be made too big, nor too small. For example, here is a little list of things that could be deadlines for a computer game project.
- Game engine (due 1 year from today)
- Art (due 1 year from today)
- Sound (due 1 year from today)
- Text (due 1 year from today)
These are some of the major components when building a computer game. You have to produce the engine that runs the game. Someone has to produce the visual and the auditory art and someone has to write text (could be in the game, could be website material). What is wrong with this list of deadlines? They have no specificity to them, and no deliverables. Which means it will be harder to determine if progress is being made within the project (no feedback).
Instead lets try goals which are tied directly to a deliverable and have much shorter durations. The actual times, deliverables and goals are going to be based on your project, theses are just used as an example, they are not specific suggestions.
- Game Engine Prototype, with 1 unit, 1 building, 1 vehicle (due in 1 month).
- Art for each of those basic entities (due in 1 month)
- Intro music (due in 1 month), sound effects for each basic unit (due in 2 months).
- Completion of the Game Design Doc (due in 1 month)
- Basic website text (due in 2 months)
Chances are that upon reading the first list team members get a sense of dread and unease as it feels like an impossibly large task with a very long time frame is looming over them. The second list, however, feels much less intimating for those who are trying to complete the tasks. There is an added bonus here. The next step is much clearer based on the second list. What do we do when the first prototype is done? Revise! Add more units. Debug. Repeat.
There should be someone on the project who can see the big picture and break it down into reasonable tasks for the rest of the team to complete. In an Amateur setting this might be the whole team discussing the project together during a planning session. Or it could be one person, a creative lead/project manager. They should be applying the second list to drive the project. If they were so inclined (or a business major) they might create a Gantt Chart or a timeline.
Monday, May 9, 2011
Jobs in computer games, where are they?
Having watched Gamasutra's career developer newsletter, and a couple other sources, it seems there is a trend in the jobs posted. Most of the work is in code or art. Having forsaken coding many years ago in order to favor business it's becoming apparent that if someone's goal is to get a job at a computer game company quickly they should have a coding education. In that light was it a mistake or a good choice to go with business as a degree?
What we all see posted are the jobs which require people in the seats right now either because someone left or because the company needs to get work done faster. Are those jobs really in the position to move up the chain? Well yes. But they aren't in the position to be higher up the chain now. Technical knowledge gets your foot in the door and you can work your way up in the business. But where are business jobs posted?
An interesting throught occurred to me today... The kind of jobs which require leadership are never posted. Existing companies don't post open jobs for the creative person who started the company. That job was already filled before a company could exist to post the job. You cant search for the kind of jobs I really want to look for, because they don't exist. After a couple months of doing this has brought up a different thought... Maybe they are never posted because they are impossible to fill. Or perhaps they are never posted because they are the easiest job to just DO, and by jumping in and just doing that job you can make a place for yourself.
Ultimately I love business as a study, and it is universally applicable to any jobs at any time in the future. I would not and could not make any other choice and do not regret my decision. Likewise I will always be making games in some way. Looking back there has always been a game that was getting some design effort, so that will continue in the future irregardless of any job in the future. This helps make me realize that being a game designer is not my ultimate goal... Working in the industry in some capacity is my goal. It's worth spending time doing the networking and learning the industry for that.
What we all see posted are the jobs which require people in the seats right now either because someone left or because the company needs to get work done faster. Are those jobs really in the position to move up the chain? Well yes. But they aren't in the position to be higher up the chain now. Technical knowledge gets your foot in the door and you can work your way up in the business. But where are business jobs posted?
An interesting throught occurred to me today... The kind of jobs which require leadership are never posted. Existing companies don't post open jobs for the creative person who started the company. That job was already filled before a company could exist to post the job. You cant search for the kind of jobs I really want to look for, because they don't exist. After a couple months of doing this has brought up a different thought... Maybe they are never posted because they are impossible to fill. Or perhaps they are never posted because they are the easiest job to just DO, and by jumping in and just doing that job you can make a place for yourself.
Ultimately I love business as a study, and it is universally applicable to any jobs at any time in the future. I would not and could not make any other choice and do not regret my decision. Likewise I will always be making games in some way. Looking back there has always been a game that was getting some design effort, so that will continue in the future irregardless of any job in the future. This helps make me realize that being a game designer is not my ultimate goal... Working in the industry in some capacity is my goal. It's worth spending time doing the networking and learning the industry for that.
Subscribe to:
Posts (Atom)