I don't like "distractions" or "time killers".
We all get one life, of variable length. I'm going to ignore religion, rebirth, and all those other theories and say that the only thing that is universally accepted by all humans is that we are born, and eventually we die, and what happens after that is mysterious.
The thing is that we are born into this amazing, wonderful world. I don't have to believe in some higher deity to realise that the world out there is full of wonder and miraculous things. In the natural world alone, there is so much to be experienced, and mankind has been quite prolific in their own right.
I find the concept of free time hard to understand, and the same of boredom. There are so many things to do in life that are so fulfilling, that I can't understand being bored and looking for something to do to kill time. When I'm not working, there are a ton of other things I like to do - learn guitar, go for bike rides, cook, spend time with my household. And when I actually "relax", even that is as a break from all the other things I want to do, and there are so many wonderful books, so much wonderful music, and even a good movie or tv show here or there.
In short, there are so many wonderful things to do in life that most days I don't even get to do everything I want. Or even close. And I'm constantly getting ideas for new things I would like to add to my busy schedule. Like, boy, I would love to make such and such game. I would love to read such and such book. I would love to bike to such and such location. I would love to learn how to play such and such instrument. I get ideas for things to do faster than I can do them.
So to me, any hold on my attention is precious. There are so many amazing things that I could be doing, why would I do something mediocre, just to kill time? I'd rather be expanding time!
I like to think that I bring this philosophy into my creative output. I never want to make something that just keeps you occupied. I never want to make something that doesn't challenge. I view everything I work on as competing with all of the amazing things that people could be doing instead, and I don't want to disappoint.
Yet strangely, these types of experiences, these "just floating by" experiences are more numerous than they've ever been. Facebook and Twitter makes it easier for us to believe that all of our friends are interested in all the mundane aspects of our lives. TV not only forces us to make do with "whatever is on", but it attempts to brainwash us into wanting more and more of these mundane experiences. The iPhone app store is awash with people making an app with the first idea that came into their head and pumping it out as quickly as possible, in the hopes that something serendipitous will happen and they will get rich.
Everybody has a voice, but most people don't seem to have anything interesting to say.
Society, especially the whole "Western" society, has reached a point where less and less time is dedicated to staying alive. We have this amazing world to experience, where we can create things that really challenge people, make them think, and have lasting impacts. We have the time to do and experience the world like we never have before in history. But we seem to have this force called "boredom" imposing on our life, that drives us to seek the easiest source of minor entertainment.
Every moment someone spends inside of a game I make is a moment that they could have been doing something else with their life. I want to make sure that it is worth the tradeoff.
Wednesday, April 14, 2010
Tuesday, March 9, 2010
Stortelling in games: likes/dislikes
I'm going to take a break from Castle Conflict related stuff to talk a bit more about storytelling in games, something that I had hoped to have more time to do but haven't in quite some time.
Specifically, I am going to look at two games, one that I think did storytelling amazingly well, and one that demonstrates how, in some way, story and related paraphernalia can hinder gameplay as much as help.
The first game I want to talk about is HalfLife 2. As far as stories go, the story here is actually not too far from the fare of most video games. There is some evil force that threatens to overtake the human race, and you are set against it to destroy it. It is a bit more interesting than just that; the human race itself seems out to get you, with police men wearing what looks like gas masks out to get you at every turn. But there are people on your side to, and they refer to you as "the free man" and even fight alongside you during gameplay.
Okay, so the story is, really, decent at best. But the actual telling of the story in Half Life is brilliant. First of all, nothing is forced on you, and I think this is a very important point about what Half Life did successfully. Yes, the game is linear; no, there aren't really any branches in the story; and yet, I felt more a part of the story in Half Life 2 than I did in games like Tales of Symphonia, where the game is -about- the story, has story scenes all the time, and allows me to make choices that effect the story. Why? Because, when story stuff was going on, I could run around, jump on things, shoot people, ignore it entirely, pay complete attention to it. In short, I was still playing the game while the story was going on, so it was still me who was experiencing the story. It quickly became something I appreciated a lot about the game.
The other aspect was the lack of detail. As you play the game, there is no moment where someone comes up to you and says, "Okay, this is what is going on." There are some light explanations here and there, but really, you're never really told specifically what the Citadel is. who "our Benefactors" really are, or how they came to be here. (note: I have never played the original Half Life, which I am sure explains some of this). The player is forced to infer what is going on based on the snippets he does here; the situation that people are living in, and the environment around him. As a storytelling technique, this makes the game much more enjoyable. And for those who don't like story, and just want to shoot things with the Gravity Gun, they can outright ignore it.
The next game is actually a series; specifically, Fire Emblem. Fire Emblem is pretty successful in the tactical RPG realm, having been releasing games since the SNES days. But there is one specific detail about it that bothers me, which I will get to in a moment.
One discussion I remember having when I was taking Game Design courses was about consequences. About how, in many games, there were no consequences to the players' actions in a lot of games. The teacher talked about how he felt that consequences could be used to greater effect in a lot of games.
I think one thing to remember with games, even games that are heavily based on storytelling, is that they are still games. They are supposed to be fun. On the one hand, I'm a fan of the idea of consequences, and I think if implemented well, they can add a lot of depth and strategy to your game.
In Fire Emblem, they added consequences. If one of your character dies in the midst of battle, he dies forever. This might not be so bad, if there weren't a lot of weaker units (healers/mages) that suddenly seem much more useless, because you never want them close enough to the front line to be used effectively. If you do this, they will be killed. And while, in this type of games, you generally don't want your units killed, in Fire Emblem having them killed basically forces you to restart the battle or move forward for the rest of the game with a gimped army. Either option kind of sucks. And unfortunately, it is easy to have a healer off by a single square, and then have an enemy unit, out of the blue, attack it an kill it in a single hit. While this does promote awareness of careful planning, which are strong aspects of this type of game. I feel that it nonetheless is a bit too harsh.
For this specific case, I think Rondo of Swords found a much better mid ground. There is still punishment if your unit dies in battle, but instead, it's just weaker in the following fight while it recovers. A much more balanced, enjoyable feature.
Specifically, I am going to look at two games, one that I think did storytelling amazingly well, and one that demonstrates how, in some way, story and related paraphernalia can hinder gameplay as much as help.
The first game I want to talk about is HalfLife 2. As far as stories go, the story here is actually not too far from the fare of most video games. There is some evil force that threatens to overtake the human race, and you are set against it to destroy it. It is a bit more interesting than just that; the human race itself seems out to get you, with police men wearing what looks like gas masks out to get you at every turn. But there are people on your side to, and they refer to you as "the free man" and even fight alongside you during gameplay.
Okay, so the story is, really, decent at best. But the actual telling of the story in Half Life is brilliant. First of all, nothing is forced on you, and I think this is a very important point about what Half Life did successfully. Yes, the game is linear; no, there aren't really any branches in the story; and yet, I felt more a part of the story in Half Life 2 than I did in games like Tales of Symphonia, where the game is -about- the story, has story scenes all the time, and allows me to make choices that effect the story. Why? Because, when story stuff was going on, I could run around, jump on things, shoot people, ignore it entirely, pay complete attention to it. In short, I was still playing the game while the story was going on, so it was still me who was experiencing the story. It quickly became something I appreciated a lot about the game.
The other aspect was the lack of detail. As you play the game, there is no moment where someone comes up to you and says, "Okay, this is what is going on." There are some light explanations here and there, but really, you're never really told specifically what the Citadel is. who "our Benefactors" really are, or how they came to be here. (note: I have never played the original Half Life, which I am sure explains some of this). The player is forced to infer what is going on based on the snippets he does here; the situation that people are living in, and the environment around him. As a storytelling technique, this makes the game much more enjoyable. And for those who don't like story, and just want to shoot things with the Gravity Gun, they can outright ignore it.
The next game is actually a series; specifically, Fire Emblem. Fire Emblem is pretty successful in the tactical RPG realm, having been releasing games since the SNES days. But there is one specific detail about it that bothers me, which I will get to in a moment.
One discussion I remember having when I was taking Game Design courses was about consequences. About how, in many games, there were no consequences to the players' actions in a lot of games. The teacher talked about how he felt that consequences could be used to greater effect in a lot of games.
I think one thing to remember with games, even games that are heavily based on storytelling, is that they are still games. They are supposed to be fun. On the one hand, I'm a fan of the idea of consequences, and I think if implemented well, they can add a lot of depth and strategy to your game.
In Fire Emblem, they added consequences. If one of your character dies in the midst of battle, he dies forever. This might not be so bad, if there weren't a lot of weaker units (healers/mages) that suddenly seem much more useless, because you never want them close enough to the front line to be used effectively. If you do this, they will be killed. And while, in this type of games, you generally don't want your units killed, in Fire Emblem having them killed basically forces you to restart the battle or move forward for the rest of the game with a gimped army. Either option kind of sucks. And unfortunately, it is easy to have a healer off by a single square, and then have an enemy unit, out of the blue, attack it an kill it in a single hit. While this does promote awareness of careful planning, which are strong aspects of this type of game. I feel that it nonetheless is a bit too harsh.
For this specific case, I think Rondo of Swords found a much better mid ground. There is still punishment if your unit dies in battle, but instead, it's just weaker in the following fight while it recovers. A much more balanced, enjoyable feature.
Saturday, March 6, 2010
Learning from your fanbase
In my last blog entry, I made the mistake about complaining about a bad review. Typically, I avoid complaining because it rarely accomplishes things, and I don't like being a whiner. But something happened as a result of my complaining - a fan of Castle Conflict went and wrote a great review. Since then, the game has got many more and with the new Egypt update out, it is doing pretty decent.Nonetheless, my last blog entry taught me two things:
1) Fans are awesome!!
2) Whining works. (Don't worry, I'm not going to start whining all the time =P)
I have a couple Castle Conflict related blogs on my plate, things that I've learned, and this will be the first of those. I was hoping to do this one about a month ago, actually, but I've been sidetracked... now that I have some time, here it is!
One of the things that we added to the Multiplayer update of Castle Conflict was a survey. The survey basically allows us to ask the users directly what they think about Castle Conflict. I set up the survey such that I could update it live, although I haven't done so as of yet, as I haven't had a chance to collate the results of the last survey.
To make the survey work, I'm using PinchMedia. It's no secret that I think Pinch is amazing and have learned a lot using it. There is some fear mongering going on about the service, but I think it's a bit too much. Especially given that Castle Conflict does not use Core Location or Facebook Connect; so some of the things that people are frightened of don't even apply to our game.
Anyways, Pinch is great because it tells you what your users do. But it's a bit more difficult to ask them outright what they think, so we added the survey. But, since we already had Pinch Media installed, instead of going through all the effort of writing a web service that would tally the results, and display it, I just made each question have a beacon, and I appended -y/-n at the end of it to mark the users response. This doesn't work perfectly; if a user takes the test more than once, for example, and answers the same question differently, I get both answers and don't know that they changed their answer. Being the optimist, I pretty much ignore all the -n answers, view by unique users instead of clicks, and tally the results that way.
Here are the results:
966 people finished the survey
945 played Campaign
918 wanted more levels
916 enjoyed campaign
909 want more units
844 want unit skins
439 would pay for more content
298 would pay for campaign levels
290 would pay for units
232 would pay for unit skins
199 would pay for multiplayer levels
307 played multiplayer
275 enjoyed multiplayer
218 thought multiplayer was stable
179 thought multiplayer had enough customisation
922 Would recommend the game to their friends
This tells me a few things.
1) Multiplayer could still use some work
2) However, very few people have played multiplayer relative to campaign
3) Despite the fact that multiplayer could use some improvements, if I were to make it more stable, I would please less than 100 people (as 2/3rds of the ~300 who had already played thought it was stable already
4) If I were to sell new campaign maps, I would please almost as many people as have played multiplayer
5) If I were to release a new, free campaign, I would please three times as many people as have played multiplayer
This tells me that, while multiplayer could use some work, the direction that the fans are interested in is campaign.
How does this compare with what I've learned via pinch?
In the month of February (when multiplayer was live):
5236 People played campaign,
972 beat it and kept playing after
1166 people created a multiplayer game
262 people challenged an existing
Result? Not a lot of people playing multiplayer in its current incarnation.
There is one other thing I would like to discuss in this entry, and that is "QuickPlay". Currently, I am thinking of axing it, despite the fact that it goes against some of my instincts. (According to Pinch, 2886 people played QuickPlay in February, so it is still being used). The reason for this is that it ruins the first experience. If the user starts a quickplay match and they haven't yet played, they are presented with 8 units + another button, and little idea what to expect. It can be overwhelming. Campaign is a much more controlled experience - the player gets 3 units to start, and gets to get new units one at a time, as features slowly unroll for them. Campaign also drives the user forward better.
If I download a game for a first time, and I'm trying to figure out how much I like it, I'm more likely to click on "QuickPlay" than "Campaign". Simply because, Campaign sounds like it has a large commitment. Whereas QuickPlay sounds light and easy - "oh yeah, I can try this out, and know if I like the game." I've seen over half the people I pass the game to test it out go to QuickPlay instead of Campaign. So either Quickplay needs some reworking ... or it should be taken away. We want users to have the best first experience possible, so that they like the game more, and are more likely to spread it via word of mouth. I think that, for this to work, we need to drive them to our best experience, which is Campaign. Will this actually happen? Stay tuned for our next update (although no date is yet set for that)
1) Fans are awesome!!
2) Whining works. (Don't worry, I'm not going to start whining all the time =P)
I have a couple Castle Conflict related blogs on my plate, things that I've learned, and this will be the first of those. I was hoping to do this one about a month ago, actually, but I've been sidetracked... now that I have some time, here it is!
One of the things that we added to the Multiplayer update of Castle Conflict was a survey. The survey basically allows us to ask the users directly what they think about Castle Conflict. I set up the survey such that I could update it live, although I haven't done so as of yet, as I haven't had a chance to collate the results of the last survey.
To make the survey work, I'm using PinchMedia. It's no secret that I think Pinch is amazing and have learned a lot using it. There is some fear mongering going on about the service, but I think it's a bit too much. Especially given that Castle Conflict does not use Core Location or Facebook Connect; so some of the things that people are frightened of don't even apply to our game.
Anyways, Pinch is great because it tells you what your users do. But it's a bit more difficult to ask them outright what they think, so we added the survey. But, since we already had Pinch Media installed, instead of going through all the effort of writing a web service that would tally the results, and display it, I just made each question have a beacon, and I appended -y/-n at the end of it to mark the users response. This doesn't work perfectly; if a user takes the test more than once, for example, and answers the same question differently, I get both answers and don't know that they changed their answer. Being the optimist, I pretty much ignore all the -n answers, view by unique users instead of clicks, and tally the results that way.
Here are the results:
966 people finished the survey
945 played Campaign
918 wanted more levels
916 enjoyed campaign
909 want more units
844 want unit skins
439 would pay for more content
298 would pay for campaign levels
290 would pay for units
232 would pay for unit skins
199 would pay for multiplayer levels
307 played multiplayer
275 enjoyed multiplayer
218 thought multiplayer was stable
179 thought multiplayer had enough customisation
922 Would recommend the game to their friends
This tells me a few things.
1) Multiplayer could still use some work
2) However, very few people have played multiplayer relative to campaign
3) Despite the fact that multiplayer could use some improvements, if I were to make it more stable, I would please less than 100 people (as 2/3rds of the ~300 who had already played thought it was stable already
4) If I were to sell new campaign maps, I would please almost as many people as have played multiplayer
5) If I were to release a new, free campaign, I would please three times as many people as have played multiplayer
This tells me that, while multiplayer could use some work, the direction that the fans are interested in is campaign.
How does this compare with what I've learned via pinch?
In the month of February (when multiplayer was live):
5236 People played campaign,
972 beat it and kept playing after
1166 people created a multiplayer game
262 people challenged an existing
Result? Not a lot of people playing multiplayer in its current incarnation.
There is one other thing I would like to discuss in this entry, and that is "QuickPlay". Currently, I am thinking of axing it, despite the fact that it goes against some of my instincts. (According to Pinch, 2886 people played QuickPlay in February, so it is still being used). The reason for this is that it ruins the first experience. If the user starts a quickplay match and they haven't yet played, they are presented with 8 units + another button, and little idea what to expect. It can be overwhelming. Campaign is a much more controlled experience - the player gets 3 units to start, and gets to get new units one at a time, as features slowly unroll for them. Campaign also drives the user forward better.
If I download a game for a first time, and I'm trying to figure out how much I like it, I'm more likely to click on "QuickPlay" than "Campaign". Simply because, Campaign sounds like it has a large commitment. Whereas QuickPlay sounds light and easy - "oh yeah, I can try this out, and know if I like the game." I've seen over half the people I pass the game to test it out go to QuickPlay instead of Campaign. So either Quickplay needs some reworking ... or it should be taken away. We want users to have the best first experience possible, so that they like the game more, and are more likely to spread it via word of mouth. I think that, for this to work, we need to drive them to our best experience, which is Campaign. Will this actually happen? Stay tuned for our next update (although no date is yet set for that)
Monday, February 1, 2010
One of the biggest fears I've heard from many of my programmer friends is showing their code to other people. Or coding in front of other people. It's as if, they're so afraid that there's some way they could be coding things better that they don't know about, that if they showed their code to others they'd be ridiculed. Or that they think that they're doing things in a great way and are afraid to be ridiculed and find out that perhaps their way isn't so great after all.
I don't remember having this fear for a long time. I got used to pairs programming in high school, which to a lesser extent involves sharing your code with someone. But it's more recently that my lack of fear has been obvious; I taught iPhone Dev School this weekend and was coding in front of an audience of ten others, not only showing off my coding style in real time, but making the claim that it was good enough that they should listen to me and code this way. (For sure, I was coding nothing particularly difficult in a two day course, but my co-instructor, Michael, came up to me and said, "Man, you're brave. Coding in front of ten other people!"
Truthfully, until he said that, I hadn't even thought about it.
No, when it comes to code, my fear is not showing it to others. My fear is my product. Michael gave a speech this weekend with roughly the following quote: "If you're not embarassed by the first version of your product, then you've shipped too late." I agree with this notion full heartedly. But although I will publish an embarassing product to see if there is any interest in it, once I know there is an interest, I get more concerned with doing things right.
I released Castle Conflict almost a year ago now. It has been a pet project of Josiah's and mine, and we have since released one minor and two major updates for it, with another one that we are currently planning. We have over 20 000 people who have downloaded non-pirated versions of the game at this point. While I am certain that it has been deleted by a number of these people, assuming only half of that audience liked the game enough to keep it, that means that each time we update our game, there's 10k people who might see it.
One of the popular requests for Castle Conflict has been multiplayer. I finally spent the time teaching myself the BlueTooth and WiFi libraries on the iPhone. I finally spent time learning about syncing, time stamps, etc. I expected that I would be done January 7th, but it was not until minutes before midnight on January 21st (after skipping my weekend and spending 4 days working 12 hour shifts, something I did without noticing because I love my job so much) that I finally submitted the multiplayer update. After days of testing, checking stability, reducing crashes, keeping the devices connected as solidly as possible. etc.
But there's a problem. I am in no means a network programmer. While I enjoyed that course in school, it was not my strong suit. And I haven't really touched anything network-program-y since 2006 in school. (Technically, I was working on Gwabs, a networked game for about a year, but by the time I was on the project most of the network code had already been written and I never touched the networking code itself). So, in terms of how to structure things, I was learning the entire way.
Then again, the first week when Josiah and I did Castle Conflict, I was teaching myself Cocos2d. But my experience with 2D game engines is much stronger, and it's a lot harder to structure rendering wrong.
On January 21st, I felt fairly certain that I was submitting a game that would be received well, that would give Castle Conflict a much-wanted boost in sales, and that was fairly certain. But I had a fear. I had a fear because I am not a network programmer, and while I tested everything I could think of, my instincts are not as sharp as they would be in searching for bugs in gameplay. I don't know with as much certainty where to look to make sure I haven't made any obvious mistakes. What if I missed a spot?
Nonetheless, surely my audience would appreciate what I had made for them, the weeks I had spent getting it working on their request, the time I had spent learning and implementing? Surely, even if there were bugs, they would understand that they would be ironed out over time, and appreciate the new features that most of them were getting for free?
Not quite so. I've got three reviews since the multiplayer update went live. One is about another game, making me wonder if the reviewer is confused, or a spammer. One was in German, and although google translate tried, it was not able to make the review completely understandable. (I did get that they liked it, though). But one said this:
"Bluetooth and WiFi gameplay always disconnects... Horrible coding and balancing."
It was a one star review, the first review lower than three stars I have gotten since campaign mode was released. And while it's too early to say for sure, my sales took a turn downwards today compared to yesterday (when this review was written). Such an early review discounts all the other stuff in the game that people have already liked, and says that it sucks because this new feature I spent weeks writing and learning for - literally as much time overall as the entire rest of the game combined - is not yet perfect. And I wonder, by spending these weeks trying to give back to my users, have I potentially damaged my sales more than hurt them? (This all being said, I just checked out this guy (NeverEverSatisfied)'s stats and he's written 14 reviews on the app store, of which 12 were 1 star.)
I'm reminded of a quote that refers to rock stars: "You're only as good as your last hit single." Perhaps this is true on the app store? Perhaps you're only as good as your last update?
I wish that the iPhone app store allowed me to e-mail people who reviewed my game. For, certainly, I would love to know what problems this guy ran into. What device he was on (I was able to test on an iPhone 3G, 3Gs, and an iPod Touch 2nd Gen, but not iPhone 2G or iPod Touch First Gen). What disconnect messages he was getting. Then, perhaps, I would be able to learn from this information, update my code, and make things more stable.
Anyways, we will continue to make wireless more and more viable as time passes. And we will continue to add more content. I have learned a couple other things from this update that I hope to blog about soon, including some classes I wrote for it.
I don't remember having this fear for a long time. I got used to pairs programming in high school, which to a lesser extent involves sharing your code with someone. But it's more recently that my lack of fear has been obvious; I taught iPhone Dev School this weekend and was coding in front of an audience of ten others, not only showing off my coding style in real time, but making the claim that it was good enough that they should listen to me and code this way. (For sure, I was coding nothing particularly difficult in a two day course, but my co-instructor, Michael, came up to me and said, "Man, you're brave. Coding in front of ten other people!"
Truthfully, until he said that, I hadn't even thought about it.
No, when it comes to code, my fear is not showing it to others. My fear is my product. Michael gave a speech this weekend with roughly the following quote: "If you're not embarassed by the first version of your product, then you've shipped too late." I agree with this notion full heartedly. But although I will publish an embarassing product to see if there is any interest in it, once I know there is an interest, I get more concerned with doing things right.
I released Castle Conflict almost a year ago now. It has been a pet project of Josiah's and mine, and we have since released one minor and two major updates for it, with another one that we are currently planning. We have over 20 000 people who have downloaded non-pirated versions of the game at this point. While I am certain that it has been deleted by a number of these people, assuming only half of that audience liked the game enough to keep it, that means that each time we update our game, there's 10k people who might see it.
One of the popular requests for Castle Conflict has been multiplayer. I finally spent the time teaching myself the BlueTooth and WiFi libraries on the iPhone. I finally spent time learning about syncing, time stamps, etc. I expected that I would be done January 7th, but it was not until minutes before midnight on January 21st (after skipping my weekend and spending 4 days working 12 hour shifts, something I did without noticing because I love my job so much) that I finally submitted the multiplayer update. After days of testing, checking stability, reducing crashes, keeping the devices connected as solidly as possible. etc.
But there's a problem. I am in no means a network programmer. While I enjoyed that course in school, it was not my strong suit. And I haven't really touched anything network-program-y since 2006 in school. (Technically, I was working on Gwabs, a networked game for about a year, but by the time I was on the project most of the network code had already been written and I never touched the networking code itself). So, in terms of how to structure things, I was learning the entire way.
Then again, the first week when Josiah and I did Castle Conflict, I was teaching myself Cocos2d. But my experience with 2D game engines is much stronger, and it's a lot harder to structure rendering wrong.
On January 21st, I felt fairly certain that I was submitting a game that would be received well, that would give Castle Conflict a much-wanted boost in sales, and that was fairly certain. But I had a fear. I had a fear because I am not a network programmer, and while I tested everything I could think of, my instincts are not as sharp as they would be in searching for bugs in gameplay. I don't know with as much certainty where to look to make sure I haven't made any obvious mistakes. What if I missed a spot?
Nonetheless, surely my audience would appreciate what I had made for them, the weeks I had spent getting it working on their request, the time I had spent learning and implementing? Surely, even if there were bugs, they would understand that they would be ironed out over time, and appreciate the new features that most of them were getting for free?
Not quite so. I've got three reviews since the multiplayer update went live. One is about another game, making me wonder if the reviewer is confused, or a spammer. One was in German, and although google translate tried, it was not able to make the review completely understandable. (I did get that they liked it, though). But one said this:
"Bluetooth and WiFi gameplay always disconnects... Horrible coding and balancing."
It was a one star review, the first review lower than three stars I have gotten since campaign mode was released. And while it's too early to say for sure, my sales took a turn downwards today compared to yesterday (when this review was written). Such an early review discounts all the other stuff in the game that people have already liked, and says that it sucks because this new feature I spent weeks writing and learning for - literally as much time overall as the entire rest of the game combined - is not yet perfect. And I wonder, by spending these weeks trying to give back to my users, have I potentially damaged my sales more than hurt them? (This all being said, I just checked out this guy (NeverEverSatisfied)'s stats and he's written 14 reviews on the app store, of which 12 were 1 star.)
I'm reminded of a quote that refers to rock stars: "You're only as good as your last hit single." Perhaps this is true on the app store? Perhaps you're only as good as your last update?
I wish that the iPhone app store allowed me to e-mail people who reviewed my game. For, certainly, I would love to know what problems this guy ran into. What device he was on (I was able to test on an iPhone 3G, 3Gs, and an iPod Touch 2nd Gen, but not iPhone 2G or iPod Touch First Gen). What disconnect messages he was getting. Then, perhaps, I would be able to learn from this information, update my code, and make things more stable.
Anyways, we will continue to make wireless more and more viable as time passes. And we will continue to add more content. I have learned a couple other things from this update that I hope to blog about soon, including some classes I wrote for it.
Wednesday, January 27, 2010
iPhone Dev School Rev 3: This weekend!
Michael Sikorsky and I will be teaching iPhone Dev School again this weekend, at the University of Calgary.
For a sample of what you can expect to learn if you attend, we have "leaked" the following recipe: BlueTooth Recipe, which outlines how to use the GameKit library in iPhone OS 3.0. This is just one of the many things that will be covered this weekend.
No experience is necessary; day one is spent getting everyone up to speed on how iPhone development works, what all the different pieces are, and getting familiar with the tools. In day two, we spend more time giving students quick introductions to various APIs that are available, both from apple and third parties. We also discuss the app store from our own real world experience.
If you are interested, there are more details on Michael's blog.
We hope to see you there!
For a sample of what you can expect to learn if you attend, we have "leaked" the following recipe: BlueTooth Recipe, which outlines how to use the GameKit library in iPhone OS 3.0. This is just one of the many things that will be covered this weekend.
No experience is necessary; day one is spent getting everyone up to speed on how iPhone development works, what all the different pieces are, and getting familiar with the tools. In day two, we spend more time giving students quick introductions to various APIs that are available, both from apple and third parties. We also discuss the app store from our own real world experience.
If you are interested, there are more details on Michael's blog.
We hope to see you there!
Saturday, January 2, 2010
iPhones impact in Calgary in 2009
2009 has seen a huge increase in the visibility of apple's iPhone App Store. The app store hit it's billionth download in May, then just before the end of September it doubled that number. Over 100k apps have been developed for the app store since it launched in the summer of 2008. Even in the humble little oil, gas, and cowboy town of Calgary, we've seen a significant pool of developers working on apps for the device.
The biggest category of iPhone app developers in Calgary have been those who are developing games. Companies in Calgary that are involved in this space include:
Broken Kings is a fledgeling Game Design company that so far has two games published on the iPhone. The first, Castle Conflict, was initially developed in 10 days, pirated over 10k times, featured by apple, and hit the top 50 in the US App Store for all apps. Their second app, Ant Attack, took longer to develop and did not sell as well. They released an update version of Castle Conflict before Christmas. The company also has two PC games that is is searching for distribution for, and does some consulting. They have one full time employee, Stephen Gazzard, and hire contractors to aid them on projects.
A lot of press has been given to Sally's Spa, which knocked EA's The Sims off of the #1 slot in the iPhone app store to becoming reigning champion. While it is no longer in the top slot, it still made makes large amounts of sales. The game was developed by a Calgary game development company, Games Cafe. The two man team responsible for most of the design, programming, and art then left Games Cafe to start their own iPhone game company, Blue Unit Games, although they were bought by Phoenix New Media shortly afterwards.
WNRS (which stands for We Are Not Rocket Scientists) and is another success story from a Calgary development house. The company includes Boris Cosic, who worked on Flapjack Finder, an app that allowed users to find Calgary Stampede Pancake Breakfasts with their iPhone. Two apps have been released by WNRS so far. The first was HallowCarver, a Halloween themed app where the users carved pumpkins with their fingers. The app was featured by apple and hit the top 50 in Canada. Their second app, a game called SnowRumble, was released in the app store shortly before Christmas.
FPM software is a company run by Lopi Mackenzie. The company is technically incorporated as a BC corporation but its offices are now located in Calgary. Their first app, ShiftMaze, was released shortly before Christmas, and developed in coordination with Vertical Motion.
Big Nerds in Disguise is a hobby developer, meaning that the employees still work full time jobs and makes their apps at night. Their first app, Own This World, went live shortly before Christmas. Is is a location based app where players gain territory using the GPS on their iPhone. In total, BNiD has three employees; two programmers and the graphic designer/marketer. (They also wrote another app, Ask JC, that was rejected by Apple).
Soma Creates is a company run by Josh Heidebrecht, a parent of two. Like many other companies in Calgary, Soma Creates makes games for the iPhone, but where Soma Creates is unique is that their apps are aimed at the children of people who own iPhones. Their first app, I Can Garden went live earlier this year, and is aimed at children 18 months and older. Soma Creates already have several projects planned for 2010, that follow their goal of creating apps that entertain children while at the same time unlocking their potential and inspiring their creativity.
Another young iPhone company in Calgary that develops games and does consulting. Notably, they recently worked on Hootsuite, which won an award on Mashable for best Twitter app.
Mindless Goods is a small Game design company based in Calgary that is near to releasing their first title, Bait, which is like a combination of the hit iPhone app Koi Pond and the hit PopCap game Feeding Frenzy. It is run by Greg Taylor outside of work hours.
The iPhoenix Fund is perhaps the biggest movements in game development in the city. It was started by Phoenix New Media, a Calgary games company that has a hit series, "Curse of the Pharaoh", on Big Fish Games. In 2009, they began iPhone operations, including the purchase of Blue Unit Studios and the start of the iPhoenix Fund, which intends to build a number of iPhone games over the next five years. Development partners that will be working with Big Stack Studios (the company Phoenix New Media is using for iPhone games) include Broken Kings, Robots and Pencils, Chayowo Games, and Phoenix New Media.
Among all the game developers, there are also some companies who dabble in more than just games.
Robots and Pencils is run by Michael J. Sikorsky and his wife, Camille Sikorsky. They consult and work on their own projects. Throughout the year, they were involved in various websites, businesses, and iPhone apps. The four iPhone apps that are live in the app store that Robots and Pencils were involved with include: Crush Factor, iHydrate, Kawi, and an app for iPhoenix Fund investors.
Finally, there have been several movements in Calgary that have not been related directly to the development of iPhone apps, yet have still benefited from the growth of iPhones on the market.
iPhone Dev School and iPhone Dev Camp are initiatives started by Michael J. Sikorsky of Robots and Pencils. He teaches iPhone Dev School with Stephen Gazzard of Broken Kings; so far, they have taught the course twice (once in Calgary and once in Edmonton). It is a weekend course, and students have gone on to write successful apps. Included among the students were Boris Cosic of WNRS, and Randy Troppman, who founded RunningMap Trackometer, an app that tracks users positions over time. (It hit #10 in the Fitness category on the iPhone). The next is being held at the University of Calgary at the end of January.
iPhone Dev Camp is a little more loosely structured than iPhone Dev School, and at the first one (which was hosted in Autumn), the "App Track" began developing an app for the Calgary Science Center.
Appboy is a website for developers to promote their apps, for people to submit app ideas, and for users to look at what apps are available. In short, it's an app-lovers hub.
iPhix is not involved in iPhone Development, but they still make their living off of the iPhone. This mom and pop shop specializes in fixing broken iPhone screens for less money and time than it takes Apple to do so.
From work-at-home entrepreneurs to hobbyists working in their free time, to large funds - the iPhone has definitely made it's presence known among the development community in Calgary. 2010 should see many more exciting advancements.
Every effort has been made to keep the content in this post accurate. If any information seems incorrect, please e-mail stephen at broken kings [dot] com
Wednesday, December 16, 2009
Gameplay and Storytelling: Part 3
I recently downloaded a game for the iPhone called Suviving High School, part 3. I was anticipating not liking it, because I am not a fan of current teen culture, and the game seemed likely to glorify it. The reason I felt interested in downloading it was because it seemed to be a game where story was important.
One of my long term goals with game development is to develop a style of gameplay where what you do in the game and what you do in the story are linked. Surviving High School showed me two things: 1) This is a viable gameplay mechanic, and 2) There is a demand for it.
Surviving High School is, in essence, a very rudimentary version of what it is that I hope to eventually accomplish. The game follows the story of you, going through high school, and along the ways you get to choose to do various things, build relationships with people, and in the end, based on how you did, things happen.
It also handles a couple of the things that I have been concerned about quite well, specifically, how to drive the player. Up front, the player is given three main goals: Win at football, Get a car, become popular. It is, of course, essentially impossible to pull all of these things off, and the player must make choices along the lines where they are going to concentrate. Are they going to make their character strong so that he can perform 'special moves' in football? Are they going to spend time studying so that they can do better at school, so that they do well enough that their dad buys them a car? Or are they going to watch TV and skip class to be come popular? (Philosophically, that's the part I hate most - that the player was rewarded for doing such things - but whatever, I won't go into a teen-lifestyle rant today :)
Where this game differs from my view on what I hope to eventually accomplish, down the road, with this style of gameplay is the characters interaction. What we have here is great - I actually enjoyed building up relationships with the various characters, and I really tried hard to have a good relationship with the girl who I was dating, and I really felt bad when other characters didn't get along well with my character. And I point out that this game does it very well, and it has excellent scripts and the characters are interesting and varied. But what I want to accomplish is a game where your interactions with other characters are richer. Surviving High School plays roughly like a "Choose your own adventure" game, where your relationship with characters is dependent on what you say in situations where you only get to choose one of two possible things to say.
I want to someday have a style of gameplay where you can go, strike up a conversation with another character, and say pretty much whatever. This of course leads to many concerns, of which syntax, performance, and possibilities are among them. I have been thinking more and more about the idea of symbolic language, as used in Siboot. (This would also solve the difficulty of porting to other languages; no having to learn how to parse multiple languages!)
Alright, so saying "Pretty much whatever" is unlikely, and it would lead to players saying dumb things to the characters. (You know that as soon as you start talking to one of those 'bots' online or wherever, you try to say the zaniest thing possible in the hopes of tripping it up). But creating a more rich, verbose interaction between characters, I believe, will really immerse the players. Because truthfully, in Surviving High School, there were many times when I didn't feel compelled to say or do either of the things that I was given the choice of doing, and felt as if I were picking the "lesser of two evils".
There is one other area that Surviving High School did well that I still would like to potentially improve upon in my own game down the road, and that is variety of actions. In SHS, the game calls on you to do many things, from sing to act to play football to etc..., and each of these things would of course require different minigames or actions to fully work. What they have instead for most cases is word based games; you spell or choose words that are related to the actions. This nicely solves the problem of having to create many different actions for the player to perform but at the same time devalues the experience of trying to accomplish some of the things your character does. While it would be difficult to create a game where the player has many options of actions on top of the various conversation requirements this game would require, I feel that finding some solution to this would be important.
At this point all of my ideas are experimental and I don't know how to solve all the problems I am encountering in my mental designs. Those that I am finding solutions for are often expensive or require vast amounts of technology and scripting times. It will require vast amounts of experimentation and iterations before this style of gameplay is fully realised. Perhaps I won't even be the one to realise it, but I hope to be involved to some degree.
One of my long term goals with game development is to develop a style of gameplay where what you do in the game and what you do in the story are linked. Surviving High School showed me two things: 1) This is a viable gameplay mechanic, and 2) There is a demand for it.
Surviving High School is, in essence, a very rudimentary version of what it is that I hope to eventually accomplish. The game follows the story of you, going through high school, and along the ways you get to choose to do various things, build relationships with people, and in the end, based on how you did, things happen.
It also handles a couple of the things that I have been concerned about quite well, specifically, how to drive the player. Up front, the player is given three main goals: Win at football, Get a car, become popular. It is, of course, essentially impossible to pull all of these things off, and the player must make choices along the lines where they are going to concentrate. Are they going to make their character strong so that he can perform 'special moves' in football? Are they going to spend time studying so that they can do better at school, so that they do well enough that their dad buys them a car? Or are they going to watch TV and skip class to be come popular? (Philosophically, that's the part I hate most - that the player was rewarded for doing such things - but whatever, I won't go into a teen-lifestyle rant today :)
Where this game differs from my view on what I hope to eventually accomplish, down the road, with this style of gameplay is the characters interaction. What we have here is great - I actually enjoyed building up relationships with the various characters, and I really tried hard to have a good relationship with the girl who I was dating, and I really felt bad when other characters didn't get along well with my character. And I point out that this game does it very well, and it has excellent scripts and the characters are interesting and varied. But what I want to accomplish is a game where your interactions with other characters are richer. Surviving High School plays roughly like a "Choose your own adventure" game, where your relationship with characters is dependent on what you say in situations where you only get to choose one of two possible things to say.
I want to someday have a style of gameplay where you can go, strike up a conversation with another character, and say pretty much whatever. This of course leads to many concerns, of which syntax, performance, and possibilities are among them. I have been thinking more and more about the idea of symbolic language, as used in Siboot. (This would also solve the difficulty of porting to other languages; no having to learn how to parse multiple languages!)
Alright, so saying "Pretty much whatever" is unlikely, and it would lead to players saying dumb things to the characters. (You know that as soon as you start talking to one of those 'bots' online or wherever, you try to say the zaniest thing possible in the hopes of tripping it up). But creating a more rich, verbose interaction between characters, I believe, will really immerse the players. Because truthfully, in Surviving High School, there were many times when I didn't feel compelled to say or do either of the things that I was given the choice of doing, and felt as if I were picking the "lesser of two evils".
There is one other area that Surviving High School did well that I still would like to potentially improve upon in my own game down the road, and that is variety of actions. In SHS, the game calls on you to do many things, from sing to act to play football to etc..., and each of these things would of course require different minigames or actions to fully work. What they have instead for most cases is word based games; you spell or choose words that are related to the actions. This nicely solves the problem of having to create many different actions for the player to perform but at the same time devalues the experience of trying to accomplish some of the things your character does. While it would be difficult to create a game where the player has many options of actions on top of the various conversation requirements this game would require, I feel that finding some solution to this would be important.
At this point all of my ideas are experimental and I don't know how to solve all the problems I am encountering in my mental designs. Those that I am finding solutions for are often expensive or require vast amounts of technology and scripting times. It will require vast amounts of experimentation and iterations before this style of gameplay is fully realised. Perhaps I won't even be the one to realise it, but I hope to be involved to some degree.
Subscribe to:
Posts (Atom)