More Musings on Game Design

Been very busy at work, but I thought I would take the time to continue my 'series' of game design blogs, and hopefully help out a friend a little in the process.

This one may ramble quite a bit, as the topic needs a bit of context in order for it to make any sense. The inspiration from this blog came from a discussion that happened on IRC in the #garagegames channel about story in games. Many people have mislabeled me as a 'anti' story guy, as I have spoken out against it in the past, but this comes mostly from my understanding of what game development is, what is a game, and how it relates to creating entertainment.

As developers, we create entertainment. I will point this out first, as in a very general sense, we seek to entertain the users of the software we create. This definition is very broad. What does it mean to create entertainment? A very hard question to answer, as many things can be entertaining. A story can entertain. An activity can entertain. An activity interwoven with a story can entertain. When one sets out to create a game, they can make the activity fun. This in and of itself is a hard thing. One can write a good story.. but given that we are not all award winner authors, I would put forth that this is also a hard thing to do well. Imagine the complexity of creating a fun activity that is interwoven with a good story when you don't have a clear command of both.

and this is where I get labeled as an anti story guy, as to aspiring developers, I always advise, focus on the game first.

So what is a game? To me, the answer is that a game is activity. When I think of games in the purest sense, there is no story. Football, Basketball, Chess, Golf. These are all games. They have no story. This is not to say they have no drama. There is a ton of drama in any game of golf. And we can enjoy both playing the game and playing it vicariously through watching it on TV. I look at these games and I think of the complexity that arises out of a set of simple rules and the act of participating or watching other participate in the game. For me, as an aspiring game designer, making a 'game' such as this.. something so pure that the act of doing it repeatedly results in drama and enjoyment, as a high watermark of the craft.

This might be because of the types of games I enjoy. I never really got into RPGs or other solitary games. back in the day, I enjoyed playing Squad Leader and Car Wars with my brothers, and with my wife, enjoyed playing Crash Team racing and Hot Shots golf. Back in college, when I had house mates, we all got addicted to Monster Rancher, which was as much a shared social experience among the group as it was a game. I really enjoy the interactive part of games. This being both the interactivity in the game and with others playing the game. I suppose this is why I am drawn to multiplayer games and other 'sandbox' style games where the game is driven by the action and not moved forward by a passive narrative.

And then there are stories. Stories are also enjoyable. We are lead through a series of events, and our brain is stimulated by the way the author chooses to present information to us, painting a mental picture of the world for us. Movies do this as well, taking us through a sequence of events (with visuals) that stimulate us and create enjoyment. Like atuhors, we are not all great filmmakers.. and given that we have all seen some stinker films (terminator 3 anyone?) I can surmise that the undertaking of creating a film is also hard.

Then there is the mixing of that which is 'game' and that which is 'story' to create entertainment. I have seen this done well so few times I can count the games which did it well on my fingers. I have seen it done poorly so many times I don't think there are enough fingers in the community to count them all (this going by my standards of what I consider good).

Now this is not to say that stories are bad. Stories can be a great thing. I love stories, and I even love some games that are story driven. But these games are often thin on the 'game' and heavy on the story. This does not make them bad, but to me, they clearly depart from being a game and move into the realm of that which is entertainment.

So, this brings me to the point of my blog. I see way to many aspiring game developers coming into this community that want to develop games, and the first thing they set off to attempt is a grand vision of creating a grand vision of combined entertainment involving a great story and great gameplay when most do not have a firm grasp of either of the separate disciplines of game development or story development. We need to learn to walk before we can run. If we don't take the time to become well versed in the discipline of creating activities (games), then how can we learn to layer a story on top of it (or through it).

As an example, I am going to pick on my friend Paul Dana a bit. Paul came to GarageGames to learn about game development, and for his first project chose something that he thought was small. He was going to recreate in a version of a classic 2d arcade game called oids. A simple concept. Fly around, shoot things, save the people, get back to the mothership. Problem was that it was trying to take a 2d game and move it to 3d.


Early on, Paul sought my advice. I gave him my opinion, which was that it was way too difficult. I advised him to work on the flying controls and how it felt to navigate the craft. He did, a little bit, and it improved, but he also started to think about level design, how to involve the mothership, the rescuing interface, etc..

Paul fell into a trap that I see many developers falling into. He got trapped by the story (in this case the thin story of Oids) and based his development approach around trying to incorporate elements of that game into his. He was not responsive enough to the actual gameplay problems inherent in the game he did have. He pushed forward thinking that if he kept on incorporating more into the game, that the problems would be solved by the inclusion of other elements that would somehow start to work together to make the game fun. He was intent on finding ways to include elements from the game he was emulating, even though their incorporation did not add to the gameplay. In an attempt to not stray too far from the game that inspired him, he focused on what he thought needed to be in there, rather than looking critically at what he was building and looking at what the game needed.

At this point, he had a problem that had become sufficiently complex that it would be hard for anyone to manage the process (let alone someone who had not been through the game development process before). Being in development creates another level of complexity as in addition to the complexity of the product itself, you add on the complexity of managing a team, managing the creation of art assets, and building the infrastructure you need to develop the product. This has a way of blinding you to the problems in your game (can't see the forrest through the trees).

To make the problem worse, Paul put a great deal of planning into the project. So much so that he stuck to 'the plan' even when it was obvious that he had made some assumptions that were flawed (leading to a development plan that was not in sync with the actual needs of the project).

Planning is a good thing, but I would like to see appropriate planning and wise choices of software development methodologies chosen to reflect the project. It pains me to see both large projects with no plan and to also see inexperienced developers making design docs that are not 'right' for the project. In the worse cases, too much planning can lead to a false sense of security that things are 'on track'. I don't see this as specific to indie projects or developers. I have seen first hand cases of where the design doc was being followed, milestones being hit, and everything looking great.. until it the game was nearing completion and was not particularly compelling.

The trick is to decide on what to plan, how much to plan, and how to address changes that will happen. For inexperienced developers, I don't think that have enough experience to act as a guide to what they are doing right and doing wrong. I recommend design docs (paper prototypes might be a better term) and project planning, but I would advise that these sorts of things be made into living documents that act as a guide and not as law.

Over time, Paul started to 'get it'. The hardest thing for him t let go of was the fact that he put of lot of really good planning into how he was going to finish the product he did have, and stuck to that a lot more than he should have. Being organized is a good thing, but in this case he had organized the creation of a game that was not all that compelling.

He has turned the corner though, and having made most of the mistakes one can make (and learning from it) he looks to be on track to end up with what I think is going to be a great product.

I could go on for a while, but I think it would be better to read what Paul has written in his blog. I am totally stoked that he is posting his thoughts on this. So few projects make it this far, that I think it is important that he recount his experiences so that others can learn from what he did right and what he did wrong.

If you are looking to get involved in the final phases of actually a game that is on the road to completion, contact Paul and let him know that you are interested in helping out, specifically, he is looking for people to help him with the 2d art for the GUI and HUD, as well as someone to help create the web page. You can find his contact info in his profile.

If you want to be a beta tester, you can check out the A virus killed my brother . If you want to discuss the trials and tribulations of Paul's journey, you can check out the So You Want To Make Video Games... thread.

I really would like to see some intelligent discussion arise in regards to game design and planning. With the IndiegamesCon just around the corner, I want to see the discussion heat up and continue face to face at the show.

ok, back to the grind for me.. so much to do, so little time.