Tuesday, November 17, 2009

iPhone Games / Return of Castle Conflict

The return of Castle Conflict / Week of no sleep round 2

It is something that's been in the back of Josiah's and my mind for months now (ever since Castle Conflict first went live in May), something that we'd intended to do a lot earlier. When we first released the game, the reviews we were getting basically said, "We love this game, but there's not enough of it!". When you have users saying, "We want more of your game!", then usually, it's a good idea to give them more of it.

All well and fair, but we felt fairly limited in what we could do. We had some significant problems, most notably, screen space; we had used up all the screen space we could, and any new units we added would require more buttons. Where would those go?

The second was, if we only have 8 units, how do we make multiple levels?

At the time, we were still of the mindset that iPhone games would not take us long to make. Castle Conflict had taken us 1 day of prototyping + 8 days developing + 1 day finalising. And those weren't full days. Furthermore, we had an idea for another game that we thought would not take long to make: Ant Attack. Surely, if we made Castle Conflict in a week, we could make Ant Attack in one, maybe two? And during that week, we could let our subconcious work on ideas for how to fix Castle Conflict. Surely, our users could wait a week for another update?

That ended up not being the case. The truth is, we don't work together full-time. I had a couple of computer games I was finishing up at the time. Josiah is also working on a computer game and a band project. To make matters further delayed, we each had a summer vacation of greater than one week planned, but neither of us at the same time.

Ant Attack ended up taking us 4 weeks of development, but because of our varied schedules, did not get released until the middle of October, at which point I was in the midst of a move. So it is with a huge sigh of relief that we were able to sit down, solve the aforementioned problems of Castle Conflict, and free a block of time to finish it.

Let this be a lesson to all future iPhone developers: Make your update for your game as soon as possible! What we should have thought in May, and will think next time, is "Surely this audience who might want Ant Attack can wait a week until our existing audience is pleased with the update they have told us they want." Because, you don't know how often those weeks of productivity are going to be available to you. And you want to address the audience that already exists, not one that might not.

What update?

In order for this to be feasible in the time we have available (once again, just one week), we are once again structuring this update in a tiered manner, and those tiers are:

1) Campaign Mode, New unit pack 1
2) Quick Play Cleanup
3) Campaign Mode Cleanup
4) New Unit Pack 2
5) New Unit Pack 3
6) Multiplayer

Sadly, multiplayer is last, and we don't really expect to get it in this update, as much as we would like to. Luckily, updating is easy to do.

Planning is Key!

We have one week for this project, so once again, we are using as many productivity tools as possible to keep things organised and moving smoothly.

1) MSN: We are working from different cities, so the ability to communicate in real time is a huge need. MSN allows us to do that.

2) XP-Dev: We are once again using this online tool to manage our tasks and plan our project. The software has been updated, so before where we had to rank our tasks by integral values to determine their importance, this time we were able to split our tasks across multiple iterations, as outline above.

3) Mockups/Flow charts: Okay, so we are very 'indy', and I use the free Mac 'Paintbrush' software to make these, so they don't look as professional as those done in Visio or another equivalent software. Nonetheless, sometimes the best way to communicate is visually, so we use images as below to communicate ideas before spending hours working on implementation and graphics for them:


Friday, November 13, 2009

Storytelling in Games: Part 2

The Game Industry likes to refer to itself as art. They like to talk about how they allow the players to have deeper experiences in the story than the player has had before. I am not going to comment on whether or not games count as art (I think it's subjective and on a case by case basis), but the storytelling is an interesting aspect.

When a reader reads a book, they often feel strong connections to their characters. They get to hear what their characters think, feel, dream, hope, etc. It can reach a point where, if a reader is truly immersed, they feel like they ARE a character. Games give players one more step into that immersion. They let players actually BE that character. But this is a problem, because games usually have the following constraints:

1) A linear or semi-linear story
2) A path for their protagonist
3) Other characters that the player interacts with.

I'm going to use Tales of Symphonia, an RPG for the GameCube, as an example of this. Let's consider the story. You play as a main character, Lloyd, who is trying to save the world. Lloyd does so by running around, killing random monsters, levelling up, and beating bosses. Over time, he encounters other characters, which join his party. Now let's examine how the above effect the players perception of themselves as Lloyd:

A linear or semi-linear story

Lloyd really has about one goal, and he can only really approach one ending. "Defeat the bad guys, save the world." The plot is a bit more complex, but that is the overriding choice that the player makes. There are certain dungeons to which the player must go, to collect certain things, to reach this ending. The player does not get much of a choice in that; they have to follow a roughly linear, designed path to 'whats next'.

Tales of Symphonia is what I would classify as 'semi-linear'. The player can make choices along the way that effect the ending, either by effecting the relationship between their character and other characters, and they can even change the end a bit. But there are finite choices that they can make, and these are NOT tied to the gameplay. Throughout the game, the player is given several binary decisions, and based on which ones they select, the ending varies. So, the player CAN influence the ending of the game, but to do so is almost a seperate section of the game then how they PLAY the game. It does not matter how many random monsters you kill, or how strong your character is. The core gameplay is not the deciding factor.

A Path for the Protagonist

In Tales of Symphonia, the player is guided by other characters and clues as to where to go next. There are not really a ton of options, for the player must hit all certain spots, and experience certain events, before the story can advance. "Side Quests" are the closest thing to additional story, but they often include supplementary or inconsequential story, and do not actually move the key plot forward.

The metaphor that the game promotes for the path to victory does not leave the player with a lot of time to figure out their own way of creating a path to victory. They must follow the path that the game has set forth for them.

Other Characters that the player interacts with

Oh boy, this is the hardest part to tell in a story. In a book, the characters have a free range to say whatever the author wants them to say, and interactions can be as complex or simple as any scene allows. The same is true for theater, movies, television, radio, and pretty much any other drama with dialogue.

But in games, we run into a problem. The player has to interact with other characters, but we can't really create verbose responses for everything that the player can say. In Tales of Symphonia, Lloyd has his own personality and talks for the player. That is one solution, although it breaks the illusion that we are Lloyd, and it works really strange with the scenes where Lloyd gives you a choice of two different things to say. Suddenly, we are Lloyd, but normally we are not? The amount we get to shape our character is pretty minimal.

Games have handled this in a variety of different ways over the years. In the Legend of Zelda, you never see what it is that Link says, only the responses that the NPC's give. So you can imagine that Link said whatever you want, as long as it makes sense with that response. In the Monkey Island and similar series, the player doesn't say anything until the player makes a choice about what to say, and then the computer has a series of canned responses. So there is more options, but ultimately, it often results in the player trying to say everything to see what they can learn from the NPC's, even if it means taking similar dialogue paths again and again.

In the Computer Science industry, programmers have been trying to get computers to talk for years. A.L.I.C.E. is an example of a bot that was scripted, but after tons of work on ai and intelligent sentence responses and parsing, the bot could still get confused by complex sentences. While the technology has doubtless advanced in the years since, it is still unlikely that the technology exists for a computer agent who could respond intelligently to any statement the player could construct, let alone adapt that entity to have a growing, changing relationship with the player, interact with the player in non-speech methods, and then expand that to have many such characters in the game world.

So, in short, this is the biggest difficulty encountering story-game evangelists. Interestingly, a method of dealing with this was developed by Chris Crawford on a Mac game in the '80s called Siboot. Essnetially, a limited number of symbols was used to represent different things that the player could say, and so the player communicated with other characters in a symbolic manner. He gives an excellent explanation of it in his book "Chris Crawford on Game Design", which I highly recommend reading.


These are only some of the difficulties that story's must overcome in games, but step one of the battle is understanding the problems to overcome.