Ramblings on Game Design

So the news is now out in the open, and everyone by now should know that GarageGames has acquired BraveTree Productions.

There was some concern in the news post, that Clark addressed in his blog. My feelings are much the same as Clarks, and I see this as a good thing for us, and a great thing for Indies in general.

I cannot talk much about what is going on behind the scenes, but good things are happening. Since we officially started as GarageGames employess, there has been a flurry of activity. Multiple projects are in the works, and the new interns are rocking the house, working on projects to extend and enhance t2d, starting on art path tutorials, and lending a hand on some big projects that are strategic for GarageGames in opening up the games market for Indies with good games.

It feels great not to be spending 2 days out of the week writing emails and talking on the phone. It is not that I did not like the people we were contracting for, it is just that our own games and tech were progressing slowly. We simply had too much going on.

GarageGames was also getting to that point where they had a lot going on.. so much that some of the smaller things were slipping through the cracks as everyone was working on 3 BIG initiatives and just did not have the time.

With the addition of our team, it is feeling good as we are starting to address a lot of the 'small' issues.. having meetings and setting up plans to fill in the gaps in the Torque tech and documentation, and make it easier for individuals to get started and to finish their projects.

There have been fears expressed that GarageGames in abandoning the Indies.. but this is very far from the Truth.

When we started BraveTree, we wanted to prove that we could make games with smaller teams and still maintain high quality. For me personally, it is a backlash against the EA thinking that games will have to cost more and be bigger. Game Development can be done cheaper and quicker than most think, and for a lot less money than people think. I am committed to it personally, and the tools and methodologies we are experimenting with are meant to show people that it CAN be done without a 50 man team and a 5 million dollar budget. We are a long way from competing with HALO, but it time, the gap will close.

And although you may not be able to start up a team and get a box deal right away, there is a path for an Indie Team to get their title on console.

With ThinkTanks for XBOX live arcade shipping in addition to Marble Blast, GarageGames now has 2 games on the consoles (with a 3rd on the way)..

I wanted to point this out as the Team that created ThinkTanks consisted of 3 people. The 'port' team for ThinkTanks consisted mainly of one person, John Quigley, doing the majority of the heavy lifting.

Total time spent on the project was the 18 man months for the original game, with another 10 man months for the xbox port. That is 28 man months total.. for a fully multiplayer game that is shipping on PC, Linux, Mac, and XBOX. Given that most of the big AAA titles requires man YEARS to complete.. I think this is a good sign that GarageGames is making good on its promise to deliver powerful tools into the hands of the masses.

ThinkTanks is not the biggest or best game ever, but it is a good game, that is a decent size, and resonates very strongly with its target audience. While not being as big a money maker as Zuma, it brings in enough that we were able to live off the income it generated, and use that $$ to grow the company. We did what Jeff suggested in his original IGC keynotes. We right sized our lives, picked an idea we knew we could complete, and found an underserved niche with a clear target audience.

On all counts, ThinkTanks is a resounding success for me. We did what I knew we could do when we started BraveTree, which was, to make a high quality game that we wanted to make, do it relatively quickly with a very small team, sell it online, generate enough revenue to stay in business, and achieve what was my dream, to take it all the way to console.. and all the while retaining ownership of the IP.

I point this out because our example proves that you can do it too. Most will struggle, but some will succeed, and I want to be that voice telling everyone that it is possible to make it happen. We did not start BraveTree with a bundle of money. We basically started from $0 and created everything you see.

If you have plans on making a game bigger than Half-Life 2 by yourself.. it is probably not going to happen. If you want to make a high quality game with great gameplay and great graphics and get it on console.. it IS possible.. and it is possible on a shoestring budget with a very small team.

I also want to point out something to correct a misconcpetion that some people have about GarageGames and BraveTree. We do work closely with GarageGames, and we do (did) share the same office building. Our co-habitation of the same office space happened several months after the shipping of ThinkTanks, when revenue from the game allowed us to get an office. During the production of ThinkTanks, GarageGames gave us no special help (unless you count Jeff Tunnells sagely advice). We had access to the same tools and code base that everyone else who has purchased the SDK has access to. We did exactly what we are advising everyone else to do. Focus on the game, make it fun, and then worry about how to make money with it. We did exactly that.

With all this talk of how you can succeed, I think it would be good if I started outlining some of the process we use that I alluded to in my last .plan.

This may ramble, and possibly end up covering several blogs, but I think it would be good to start at the beginning.

IDEAS

Ideas. What is a good idea and a bad idea. Jeff says "ideas are a dime a dozen". and I am inclined to agree. How does one separate the good ones from the bad. Well, when I have an idea, I ask myself some questions. The main one I ask is, "can this be done by the team we have". If the answer is yes, great.. if the answer is no.. then the idea sucks as a choice for prototyping. Sorry if this seems harsh.. but it is reality. If you have no way of finishing the project, there is not really much point in starting it. I have a backlog of ideas that are waiting in the wings once the team and tech have progressed enough to handle them. Ideas that are doable by the team you have are the best choices.

After you determine that the project is doable, you have to look at the intended audience. Who are you making the game for? As an Indie, you need to serve a market or you will not get sales. If the audience you are shooting to serve is already being offered enough, you will be in competition with them. It is best to choose a very specific niche and serve them. Serving the same niche as Unreal Tournament is not a wise move unless you can deliver everything the audience expects from a title in that niche.

As an example, I will use ThinkTanks. The intended audience for ThinkTanks is an audience I call ex-Doomers. This audience consists of individuals who used to be hard core doom addicts 'back in the day', but now have families, kids, and not a lot of time. What we wanted was to give to this audience an experience that was similar in feel to a shooter, but did not require the investment of 40 hours a week of constant online play to remain even slightly competitive. This was an easy target for us to shoot for, as I am clearly in the target audience. I know what I like and don't like about the current offering of games, and the game was crafted to respond to that. By all accounts, the audience we intended to hot was hit, and hit strongly. Strangely, it seems that we happen to have a dis-proportianate number of graphic designers and video professionals (on the mac) who LOVE our game.

lastly, there is something we (Jay Moore and I) called the 'duh' factor. The duh factor is the thing that communicates to the potential game demo-er what the game is. ThinkTanks is a great example. What is it about? duh-- tanks. In the sea of free demos out there, this jumps out to a potential customer. They see the name and the screenshot, and they have a pretty clear idea of what the game is about. Phil has hit upon the brilliant name of 'AirAce" for his game. One look at the name and a screenshot, and you 'get it'. Joshua Dallman made a really good choice with 'Shelled'. The Turtle/Artillery theme hit the mark.. the humor is apparent, and the shots of the big cannons let you know that this is an artillery game.

The best ideas are those that a game player can connect with immediately. If it takes longer than it takes to read the name and glance at a thumbnail for the potential downloader to 'get it'.. then you don't have the 'duh' and it would probably be advisable to rethink the theme or the name until the customer can get it right away.

It is not all just in the name.. it is the name and the look.. and what kind of response it brings up in the potential customer. In this case, baggage is a good thing. If you want to bring up memories of 'Terminator'.. and your game is meant to appeal to those who liked the terminator series, then visual associations with it are not at all a bad thing. The name helps a lot though.

So, that is, to me, what makes an idea good. It can be done by your team.. you know and understand the audience, and you choose a theme and name that will resonate with them very quickly.

IMPLEMENTATION

Implementation is where is all happens. A bad implementation can make a good idea suck, and good implementation can make a marginal idea sing. The people doing the implementing are the people who make a game. As a designer/director, the job is not to spell it out on paper and walk away.. it is to guide the process from start to finish.. Earlier I stated that ideas are a dime a dozen. This is why I expect each person I work with to be generating $3-$4 worth of ideas daily. The process of making the game is responding to what has been implemented, seeing what works and making it better, and chucking out that which does not work.

It is the people who are building the product who make it what it is.

A clear example of this was the new 'locking' reticle in ThinkTanks for xbox. We knew where we wanted to go, but getting there was a struggle. Clark, John, and Matt all took turns tweaking different parts of the new interface, and without them having a 'feel' for what worked and what didn't, I don't think the aiming model would have turned out as good as it did.

How does one implement an idea. It has been said before and I will say it again. Prototype and iterate. Iteration is key. Think about what is fun, put it into a prototype, and test it. Test it as often as you can and test it on people who are in your audience. Listen to feedback.

Those who saw early builds of ThinkTanks know that we practice what we preach.. Early builds of ThinkTanks has box tanks and box explosions with a stick for the weapon. It played well, and we invested no time in the art. If you want to keep the game cheap, delay the art production until as late in the process as possible, so that you don't end up spending a LOT of time making assets that will get thrown away.

I will have more on the actual prototyping and iteration process in a later blog, but I wanted to address more topics, and specifically,

THE DEMO

Almost without fail, most indie games I have seen have blown it on the demo. I try a lot of games, and most don't do the job of making the sale. Many times I enjoy the game, but I don't have a clear idea of what I would get if I get the full version. Other games don't do a good job of getting me into the game and getting the experience quickly enough to see if I like it. One demo in particular had officemate Mark McCoy remarking "seems like it might have been good, but I did not get that far into it as the shell kicked my ass".

If you want people to buy your game, you have to be sensitive to the consumer and create a compelling demo for them so that they get the experience of the game quickly, understand what they get IF they get the full version, and create compelling reasons for them to purchase.

Most demos I play seem as if they were done at the last minute, right before the game is shipped, and often are nothing more than a time limit on the full game.

Time Limiting can work, but not all games are the same, and not all games will benefit from the same demo strategy.

If there is one thing I would offer as advice to developers, it is to think about the demo strategy as early in the development process as possible (ideally during the design doc phase).

For ThinkTanks, we not only looked at games, but also all types of shareware that we use. FTP apps.. little utilities, etc.. and made a list of which ones we ended up purchasing, which one we did not buy, what strategies they used, and what we thought was successful.

What we settled on for ThinkTanks was a combination of feature limiting (making sure we made the features visible, but disabled), time limiting, and 'annoy' screens. The ones that worked best were the feature limiting of the tanks.. you got to see the tanks that you could not choose, and the 'kick' you get when playing multiplayer with the nag screen that reminds you that you are a demo.

We added a bunch of smaller 'annoy' features, like demo versions not saving the players name between games (so you had to keep retyping it in).. many small constant reminders that you are a DEMO and not a retail player.

We also tracked data on downloads and conversion to tune the demo, the text on the product page, etc.. to see what we could tweak to make the demo experience better.

ANALYSIS

Both Clark and I are data hounds. If it can be tested and measured, we like to test and measure it. This is not to say we are wholly analytical.. in fact, both of us consistently work from 'gut' feelings about things, and rely on a lot of intuition when making decisions. If it feels right, it probably is. BUT, we do like to double check our assumptions about things. This is why we track data both formally and informally. For optimization, clark does some really in depth analysis of the situation. It is really cool to see charts and clear data that backs up his assumptions on where problem areas are. For myself, at the IGC, I am walking around, watching people play games, timing how long they play, which games are showing up on the screens in the play area the most.. where people look like they are having fun, keeping an eye out for people struggling with interfaces.. all so I can learn and gather more information to make better decisions.

The more information one has, the better informed they are and the better decisions they can make.



ok, I am running out of steam for the evening, and tomorrow is Monday and I have a boatload of work to do, so instead of having this sit on my harddrive, I am just going to post it. I hope some of you find my thoughts useful, and if there is anything anyone would like me to expound upon, let me know.

As for the picture at the top of this blog, it has nothing to do with anything I wrote, I just hate having blogs without pictures.