Tuesday, August 24, 2010

The disconnect between story and gameplay pacing in RPGs

Soren Johnson has recently written a couple of posts about the disconnect between theme and mechanics. One example he gives is applicable to just about any free roaming RPG like the Elder Scrolls series. The theme, or story, is about being a hero and defeating some huge evil. However, the mechanics are about scavenging, hardly heroic stuff.

In this post I am going to consider another disconnect that occurs in this genre: pacing in gameplay and narrative. The story will be telling of an impending threat and that speed is of the essence; the gameplay will be rewarding you for taking your time and actively avoiding advancing the story. I must have played Oblivion for about 100 hours and countless in game days, I have become leader of the Mage's Guild, gone on a killing spree and numerous other things and the imminent threat still hasn't actually developed (except when I try to deal with it).

All of this stops the story meaning anything. The threat never feels genuine; yes it would be nice for you to defeat it, but if you don't, it's no big deal. Instead, I think that stories should be crafted to match the inherent gameplay pacing of an RPG.

One example that came to my mind recently is global warming. It has the same giant scope as a normal story - the end of the world - but the time scale is in terms of years rather than days. This will allow players to explore without feeling like the threat is made up. It could also be worked so that the gameplay of scavenging, or recycling, fitted with the theme as well.

Thursday, June 10, 2010

A puzzle game - Weeping Angels

The basic premise of this game is based around the BBC drama Doctor Who. One recurring race (well, recurred once) of aliens are the Weeping Angels. They move incredibly fast and then kill you. The catch is, they can only move when no one is looking. While someone looks at them, they appear to simply be stone statues. This makes for some properly scary drama and feature in my two favourite episodes of Doctor Who. However, it also suggested quite an interesting strategy game to me.

Or a puzzle game. Troy Goodfellow describes strategy games as elaborate puzzle games (or something to that effect). I think it is more a gradient and this got me in to an interesting discussion on twitter about the merits and demerits of single solution puzzles. That for me is the difference between a strategy game and a puzzle game. In a strategy game, you are given a set of rules and tools and then you have to work out how to defeat the opposition: a puzzle to solve, but one with an infinite (or seemingly infinite) number of solutions and where there is very rarely a right or wrong answer.

At the other end of the spectrum is something like Braid where only one solution exists and you must work out what this is. Games like this are much harder to get in to - you can't just mess around and hope to achieve the answer (at least once you get to the more challenging end of the game)

Obviously you get in to hazy semantic battles here: is Peggle a strategy game; it does have multiple solutions. I would argue yes because you don't work out the entire solution; instead you analyse the situation and work out a logical next step.

The basis of the game would be you would have a set number of people who you have to get from one side of a room to the other. They would each be capable of looking in one direction and while the angles were in their line of sight.

So the question is do I make this a strategy game or a puzzle game (by the above gradient). Do I create each room so you have to move and place your people in a specific place to get across the room, or do I make it more tactical. It would certainly be possible to mix it up, or even choose something in the middle such as elements of the room that have to be solved in one way, but a lot of it could be done in a more free way.

Wednesday, April 14, 2010

Scale (Or "I am important too")

When multiplayer digital gaming was new, there were huge technical hurdles with everything developers tried to do. As a result, games blindly sought greater technological achievements such as number of simultaneous players. While these issues still exist, they are quickly becoming less significant with wide spread broadband and fibre optic cables quickly becoming main stream.

(For this post, I will assume we are talking about a shooter, obviously MMO games have many more simultaneous connexions, but that is something different).

Everyone likes the idea of hundreds of people all playing in the same game at the same time. You can truly create that war time feeling with bullets whizzing past you and players shouting. Suddenly it isn't you charging some enemies, it is you and loads of other people. It sounds really awesome.

However, I don't believe we should simply be going for as many people as technically possible. Halo 3 supports 16 players in a 8 versus 8 battle. I think this is pushing the limit for standard first person shooter mechanics. Already, you start to feel insignificant. In a balanced 4 versus 4 game in Halo, each death matters and each kill feels like cause for celebration. In Big Team Battle, this simply isn't the case. You charge in because one death is trivial; there is no tension.

I believe the more people you add, the worse the problem will get. Does this mean that I think that large count first person shooters are doomed to failure despite sounding awesome? Well, no.

Instead of giving up, a large scale game needs extra work to make the player feel significant. If every player is doing the same thing, then each players actions become virtually irrelevant: if they fail, either someone on their team will do it, or it won't be their fault because everyone failed.

Instead I think large numbers should be used as a backdrop for smaller games. You and a small group of people would be tasked to doing something. There would be an equal group on the opposite team tasked with doing the opposite. The players could still kill people who are not directly related to their mission, but it would not count towards the final score.

The problem with this is then you are not really a team, just lots of games going on on one map. Sure, you still create a sense of scale, but without a sense of being a team, you would feel no compulsion to attack the other team. I think this would almost completely counter balance the benefits. How many wars have enemies walking past one and another not shooting because they are not related to what they have been tasked to do. The player would be frequently and strongly reminded that they are not in a war, defeating the entire point.

The obvious solution is to have each teams success count as a point towards its team. The problem with this is then you get back to the original problem: getting that point doesn't matter, you won't win because of that point or loose by your failure. While it may not be a complete solution, I think it does reset the counting. If you have 8 players per team, then your kills don't matter. But if there are only 4 teams of 4 per side, then you have 16 players per side (so double) but you would hopefully have the tension of a 4 on 4.

Sunday, March 14, 2010


I was walking back from baby sitting tonight and I realised that late at night was actually one of my favourite times to be walking. Everything is so quite and still. I think the reason it is such a nice enviroment is because it is such a juxtaposition to the norm of everything moving and making a noise. It gives me a chance to reflect on the day, I don't have any music, there is no one else about, no rush and my mind is already winding down.

It got me thinking about how rare stillness is as a game enviroment. As we strive after ever more realistic graphics with more interactive elements, nothing is ever still. The idea of intentionally leaving an area empty of people, animations and sound is almost unheard of. Even the peaceful evenings on Assasins's Creed 2 still have people milling about.

One thing I have been thinking about is the idea of pacing in games. For a lot of games, the designers expect players to manage their own down time. Playing though Call of Duty for example, if you want a breather, you have to stop the game; the story doesn't have any slow paced sections. I think the idea of of stillness is tied to this: designers are unwillinging to provide a sensorly underwhelming experience in the same way they are unwilling to intentionally let of the action.

I hope anyone who went to GDC had a nice time, some very interesting talks and I can't wait for Fable 3.

Sunday, January 3, 2010

Outlook of 2010 for Botworks

One of the main reasons I started this blog was as a way for me to keep track of my ideas and projects. So, in that context, this is more of a post for me, as it is a rough plan of what I plan to do this year.

Frozen Kangaroo, the real time strategy game I am making has been put on hold. This is for a number of reasons. The most important is simply that I have learnt so much since I have started that I have emerged on to the second stage of ignorance: aware of my failures (the step before being incompetent AND unaware). As a result, I can look at Frozen Kangaroo and say it is a lot more complicated than I thought and needs full planning.

I need to find you what works for me. My Computing coursework has helped me in this respect, but there is still much I need to learn. However, Frozen Kangaroo is too big for me to experiment with

Instead, I am planning a couple of much smaller projects. The first one I am allowing only a month to complete. I will have more details out soon, but I will briefly explain what I am trying with the planning. I am using a free piece of software called Freemind which allows me to create mind maps. Now, none of this is new, but I have never really done it properly. What I am going to do is break down each part of the game in to tiny little components that may be one algorithm or object.

The aim is, if I can make sure I know how to do each component, then theoretically I can make the whole game. The problem I had with Frozen Kangaroo, the nail in the coffin if you will, was that I needed to enhance an existing feature to include extra functionality. However, the feature was woven in to the very fabric of the game and when I changed it, everything broke. My hope is, with these tiny parts, each part will equate to one function that will have a fixed output and once they are done, they are done.

The second stage will be drawing up a schedule. I said that I would limit myself to one month. That means, that at the end of one month, I will publish everything I have made if it works, and if it doesn't, I move on with only a post mortem to remember it by (where I will try to decide what I did wrong)

I hope to start this one month project in February but I want to draw up a plan before I start and I have exams in January, so it may be more like half way through February. If all this goes to plan, I will begin planning a 6 month project. Hopefully, this will lay quite a lot of ground work for Frozen Kangaroo as it will have similar planning challenges as FK.

I also want to learn how to use Unity. I don't plan to make anything particularly noteworthy, my rough aim is to make a game set on an island where you must collect 8 items to help your escape. Hopefully, there should be just enough there for me to learn the basics of Unity.

The big thing for me this year is going to university. Don't ask me where I am going, I don't actually know (:S). Also, as it will be the last year at school I plan to go on holiday with my friends during the summer. None the less, I would still like to get the proper Bot website up and running, whilst maintaining Veteran Gamer, this blog, my school work, playing games and all of the above.

I hope everyone had a merry Christmas and a happy new year. Hopefully this time next year I will have 2 games to my name, an understanding of planning (and Unity 3D!) a place at a university and ready to restart Frozen Kangaroo. Bon Voyage!