Blog for Joe Maruschak at GarageGames.com

Focusing development by way of bootstrapping

Joe Maruschak — 2006-11-07T17:11:50+00:00

boot-strap-ping To promote and develop by use of one's own initiative and work without reliance on outside help.

As part of my planned series on game prototyping, I am feeling that I need to lay out my opinion and theory of game development and project management, because I feel that one cannot divorce the two topics.

Game Development cannot be separated from decision management. Creating a game is all about making many small good decisions during the creating of the game. Good games are the result of not one brillaint idea, but thousands of small good ideas and thousands of small good decisions. The best way to practice making good decisions is to practice making them. The best metric for seeing whether or not you are making good decisions is to make decisions in an environment that rewards good decisions and makes very clear bad decisions that are made.

Bootstrapping is such an environment.

If you start with very little, it forces you to immediately make a decision that will get you moving forward. If you make good decisions, your project will move forward. If you make bad ones, you will not make progress. If you can make a game while bootstrapping, you are getting the best practice that one can get in making good decisions. It may be a fairly brutal and darwinian process, but it really rewards those who have what it takes to manage projects and complete games.

Bootstrapping forces you to ask yourself, what is important right now. You can cut through the crap and cut to the chase. What is really important? What about cutscenes? sound? music? when you don't have the resources to pay for all of these things right away, you are left to contemplate the core of the game you are trying to create. What is at the core of it may not be immediately apparent. Bootstrapping forces you to thnk about it and decide where you are going to focus your precious resources. What is most important to focus on now.

If you make the right decisions, you will be rewarded with success. Your game will slowly come together, becoming more fun and more engaging each day, and it will gather it's own momentum. If you make the wrong decisions, it will seem like an uphill climb, with each task a chore, the game not progressing, and motivation waning.

When you have little or nothing to work with, or when you are working alone, you have little you can waste. If you spend all of your time on things that really matter, you will have optimized your development process so that when you tackle bigger, harder projects, you have the skills to make the right decisions more often then not.

Often I read threads about developers who 'don't have enoiugh funding' or 'the team I have cannot complete the design we have' and I almost tear my hair out in frustration. If the first decision one makes is to undertake a project that they have no chance of completing and they are fully aware that they are resource constrained coming off the starting blocks, how are they ever going to learn how to make good decisions?

My own theories of how to make games the 'right' way deal specifically with forcing decision points at the right times, and assessing and addressing the risk level associated with each implementation item. Often times, it is experience that allows one to understand what are 'big' features and what are small, and what constitutes a risk to the project. Knowing what is a high risk item and what is low risk will help you to properly assess what should go into your priority queue.

What constitutes a risk is different for every team. Every collection of 'resources'(people) comes with a unique set of skills and experience. Knowing what you can and cannot acheive is key to understanding what might constitute a risk to a project.

Knowing your team is step one, knowing the project is step two. I try to break whatever I am working on into small understandable chunks, or work items, so that I can look at them objectively, and break them down into implementation items. Implementation items allow me to look at each one and decide, this item is very important, and these other items are not so important. As an example, the external art design of the GUI for a racng game needs to be done, but without a driving model, there is no game at all. This is an example that is very obvious, but I have seen many examples of projects that have gone very far down a path where the core gameplay was not yet proven.

Bootstrapping forces the issues to the surface. If you have little resource, you need to be selective about what to work on. In order to be selective, you need to have items to select and you need to have some process to select what you think is important. Good decisions happen when you can pick the right things to work on and don't waste time.

Many of the agile development methodologies are based on the ideas of iterative prototyping and rapid development, and give one the tools and process to help decide what one works on and what is put off until later.. I highly recommend looking over some of them and lifting whatever you can from any of them and incorporating them into your workflow. I would not suggest blindly following any of the methodologies, as they are just tools. Pick up anything that seems useful, discard anything that is not helping you to focus on the task at hand, which is deciding what you need to work on to get your project done.

I am not going to go into many of the agile methodoloies in depth as I go over my ideas about prototyping. I am going to keep it very general and very high level. The main idea behind everthing that I feel is important when prototyping and creating a game is to know what is important and what needs to be worked on next. To me, it is all about setting priorities, and keeping them in order.

If you are making good decisions and keeping your priorities straight, you will make progress. If you don't, you won't. It is important during the process that you are aware that every decision you make about what to work on (and what not to work on) and what is important (and what is not) contributes to your success or failure.

When in bootstrap mode, any failure or bad decision hurts, and it is immediately apparent. Time is of the essence, so learn not to waste any of it. If you start with very little, you have very little to lose, so move forward and learn to make the decisions that will take you to the top, and not leave you stuck

an excellent blog on Agile Development on Ganes From Within, which was referenced from Lost Garden can be read here. I would suggest reading it and applying whatever concepts seem appropriate to your development practices.

New Human 2.0

Joe Maruschak — 2006-10-20T16:55:54+00:00

Welcome to the World, Jonathan William MacGregor Maruschak!

Weight: 8 pounds and 13 ounces
Length: 20 inches
Time: 12:50 pm
Date:Monday, October 16, 2006

There are more pictures here. My next blog will get back to the promised 'development series'.. after I catch up on my sleep.

The Finish Line

Joe Maruschak — 2006-09-30T16:39:42+00:00

Whee! I can finally talk about one of the things I have been working on during the last year. This week, Rack'em Up Road Trip shipped on MSN!

Rack'em up Road Trip reperesents the first commercial title that was developed in house at GarageGames (in partnership with Oberon Media) using Torque Game Builder, and demonstrates our commitment to 'eat our own dog food'. With every peice of technology we make, we feel compelled to put it through its paces and give it a real world run through the guantlet.

We started Rack 'em up Road Trip last year with a pre-release version of Torque Game Builder. Starting in early on the engine development process, we worked hard by tackling what is actually a pretty difficult project.

First, we had to match the feel and rules of a game that people have real world experience with. We could not ignore interface issues that were not working or change the rules if things were confusing. We had to work toward solutions. There were a myriad of small interface issues with foul reporting, communicating the players which balls were 'legal' (particularly with snooker), and challenges with the AI in getting them to be fun enough to play against. Additionally, we upped the ante by adding some sort of movement 'bling' to every GUI screen. Very little of the in game navigation is done on static screens. We made a pretty big game, and we still kept the download very reasonable (in the 10MB range) and kept memory usage low.

We faced many difficulties and challenges, and in the process, TGB became a much stronger engine because of it. What did not work, we had to fix, where the workflow was not usable, we created tools to help speed the process along. We suffered through this pain so you guys did not have to.

We knew going in that this would be a hard road, and we also believed that the engine, even at that early state, was up to the challenge we were taking on. TGB measured up, and did not let us down.

I want to send out a massive thanks to the team, Robert Blanchett, who took the lead on programming and was with this project from beginning to end, Mark McCoy, without whose help the game would not look half as good as it does, Zach Zadell, without who we would have no single player game, Justin DuJardin, who was instrumental in giving us our whoosy, blingee GUIs. A shout goes out to Adam, Clark, Pat, Jeff, Josh, Melv, Paul, Eric Elwell, and everyone else who contributed to getting this game accross the finish line.

Check it out!

Value of a Thing

Joe Maruschak — 2006-09-03T16:47:48+00:00

Sorry for the few months of no blog posting. I was away on vacation in July for 3 weeks enjoying some much needed R and R. After I got back, demos for TGB, TSE and GameFest took over my life.

This is the 'value' blog that I promised I was going to write in one of my previous blogs. I wanted to get this one out of the way first, and it was very hard to write. I hate addressing issues that are amorphous, that I cannot fully wrap my head around. The 'value' of a thing, and in particular, games, is a tough nut to crack. Most of the time the idea of the 'value' of a game is an educated guess. I suppose that this is why it is important for me to write this, as all too often I see people starting off making their game with no thought as to the end value of the project to the consumer, or even clarifying in their heads the 'guess' they are making. This blog may read like a stream of conciouness ramble, so apologies in advance if it lacks coherence.

I am going to warn everyone reading this that I will ask a lot of questions, and not give many answers. The goal of this blog is to get everyone thinking more deeply about the value of anything they consume, hopefully become a little more introspective about their own value system, understand what you will pay for, and apply this knowledge to the production of your own games.

So, first off, I am going to talk about the perceived value of things we purchase and consume everyday. I am going to lay it on the table and say that the perceived value of some 'thing' has no relation to the actual value or the item in question, and has a lot to do with the social conditioning of what we expect to pay for items.

For a movie in a theater, you can expect to pay $8 for a ticket ($16+ if you bring a date and buy popcorn). Most movies run about 90-100 minutes, so you are paying at least $5/hr for the entertainment. For DVDs, renting one is about $3 a pop (and given the noraml viewing habits of most families, this is about the cost of NetFlix).. a little better, but still about $2/hr.

Broadway plays and rock concerts can be even more expensive, often running as much as $25/hr for the cost of the experience. People can attach a high dollar amount (value) to these one time, non repeatable life experiences.

People will pay for things of high quality. What sort of quality attaches to a 'thing' is hard to ascertain. Again, social conditioning has a part to play. We pay high prices for electronic components (TVs, Computers) and things that are large (appliances like refrigerators and dryers). We expect that a better car will be of a higher price. We have associated brands with quality of and item, and become loyal to brands that have, in the past, provided good value at a good price to us.

The way people pay for things and understand how to 'acquire' that which they like is changing. iTunes now enables the end user to pay $1 for an individual song. No longer do you have to shell out $17 for a full CD and gamble that the rest of the songs are as good as the one you heard on the radio (usually they are not). The idea of paying for only exactly what you want is catching on.

The iPod is also a pretty godo example to look at. mp3 players had been around for a while before the iPod came out. What apple did with the iPod and iTunes was to streamline the experience. Purchase, plugin, and play music in less than 15 minutes. The 'no hassle' experience of buying an iPod is what set it apart from other players and gained it market share (and in fact made it synonymous with mp3 player). The quality of the item is not related to the item itself, it is the whole system, and what it provides for me, which is hassle free setup and operation.

In one of the books I read on business, FedEx was used as an example of how people attach value to something. FedEx realized at one point, that they were not selling shipping services. They realized they were selling an idea of security. You use FedEx when it 'absolutely, positiviely needs to be there overnight'. They recongnized something that people attach high value to, delivered it for them (at a pretty high premium), and caputalized on it.

Netflix allows you to get DVDs without ever heading to the video store. Why is netflix so successful? I am sure that everyone reading this has been to the video store to get the latest DVD release they have been dying to see, only to get there to see that the DVD in question is all rented out, and that the mountain of 'other' possible stuff to rent is hard to parse and search. I know I head home dejected, often with no movie in hand, when the one thing I went to the store for is not available, and after having spent an extra half an hour looking for 'something else' to fill the evening I had planned to spend watching a movie. Netflix saves me time. I can search online. I don't have to go to 'them'.. the movie comes to 'me'. I am not placed in indentured servitude to the video store to drive the damn disc back. Netflix gives me power over my life and my time. It puts me in the driver seat.

XBox Live Arcade enables users to purchase games for about $10, without ever heading to the store. It allows me to try games before I buy them, and not experience the dejection of paying $60 for something that I was SO excited about for months (buying into the hype) and then come home to realize that it is not the experience I wanted. Again, this puts me in the driver seat of buying what I want, and only what I want, and not parting with my money unless I have decided the value of the item is high enough for me to pay for it.

In Dan MacDonalds blog, he wrote:

customers don't care how much time and energy you put into coding the game, they are only interested in two things. The games design and it's production values. This is what customers will be willing to pay money for,

When I see a lot of new developers come here and talk about their games, I sometimes cringe that their design docs measure quality by the pound. 40 races with 20 unique classes, 80 levels, 25 game types.. my opinon is that this often happens because of the assumption that people measure things numerically. More is better, right? Well, yes and no. All things being equal, an item with 'more' for the same price is probably going to be more desireable. But 80 levels of something that sucks does not necessarily make it something that inspires people to purchase it.

So, does more matter? yes.. but only if the thing that people want 'more' of is of sufficiently high quality.

Determining value of a game by the poundage is not a very sophisticated way to think about the problem, and while more is ususally better, it is more likley that you will sell a small great game then a very large mediocre one. Designing by the pound is a dangerous road to travel for development as well. If you proceed with blinders on to the quality of the game, and march on creating 80 levles of crap-tasticness, you will sink a lot of time into something that will not pay off and few will ever see.

How much should one add and how big should it be? the answer is 'just enough'. Too little means that the end user will not place value on it, and 'too much' means you spent too much time and too much resource on the game.

As a testement to the sell-a-bility of the small, ThinkTanks has 3 vehicles, 12 levles, and 2 game types. It still keeps on selling. More is not always better.

So, how does all this apply to how one goes about creating games?

That part is up to you. The value of a thing is based on the perception of quality. Is the game high quality? does it provide an experience that is worth the money and time that one is willing to pay? That question is hard to answer, but there are a few things that can be done.

The first thing is the production quality. All things being equal, your product must be of the highest quality that you can muster (as in, the highest quality you can afford to spend given the expected return on the investment). Production quality is a subjective issue, and good screenshots and demo videos can go a long way toward creating a perception of quality. It can also be the downfall of the product. Poor presentation will lose a lot of customers before they even download.

I would suggest to everyone that they look inside themselves, to think of screenshots, movie trailers, game trailers, and ads that got them hyped. Ask yourself, what about this got me hyped? What buttons did it push in me? Why am I responding to this so strongly and so positively?

Look to ways to positviely present your project as high in production quality, and attempt to do so in as low cost a way as is possible.

The second thing one must do is provide a compelling experience. The game must be really good to get people to purchase it.

Much of what you might pay for can be gotten online, often for free on the gaming portals. If an hour of an experience is enough for you, for any one game, you can go from demo, to demo, to demo without ever buying it. You have to provide something that the person wants, and is willing to pay for.

And what are people willing to pay for?

With ThinkTanks, we did some things that we think helped. First, in the demo, we appended [demo] to your name. This lets you, and everyone else know that you are a demo player. We also did not allow saving of your name in demo mode. In the demo version, you are a nobody, and everyone, yourself included, knows it. We leveraged this even further by kicking the demo players from MP matches after five minutes. Kicking them out of the game effectively zeros out your score, so the demo players can never win (well, they can, but they have to be good). This reinforces the notion that you are a nobody and you cannot win. Lastly, we made the meduim tank (the default one, and the only one you can access in the demo version) less desirable looking and less desirable in performance than the light and heavy tanks. You crave what you cannot have. You are a nobody, you cannot win, and you cannot get the coolest tanks.

We made the gameplay fun, which was the first step, but then we set it up so that the player would be presented with a choice that gave them value. If they purchased, they could win, they could have a name, and they could get the cool vehicles. We provided value with the game, but we set up a system in the game that had players perceiving additional value to the purchased version.

This seems like a no brainer, but a lot of good games I have played did little or nothing to let me know what I was missing out on when the demo expired. I left the game thinking.. well, that was satisfying, next.

And this is the million dollar questions. What value does a game need to provide? first and foremost, it has to be fun. If it is not fun, if it does not compel the player to play it, then you will not get any sales. After that, it is a guess. What else can you do to convince the player that your game is worth paying for? what do they get for their $$$?

the simplistic answer is.. a game. The more complex answer is best demonstrated by the FedEx example above. What people pay for (shipping in this case) is not always what they are buying (the reassurance that the 'stuff' will be there tomorrow). This is something to ponder as you work on your game, as it can make the difference between a great game and a great game that sells.

so, not many answers, lots of questions. Questions you should be asking yourself constantly, thinking about, and answering for yourself as you make the decisions that decide the course of your development. When I am working on a game, I am constantly asking myself, would I pay $20 for this? If I cannot answer yes, then I know I have more work to do.

whew.. hopefully after this one, the rest of my planned blogs will be easy, and I can get back onto my planned blogging schedule.

The shape of things to come

Joe Maruschak — 2006-06-18T19:14:53+00:00

I have a long list of blogs that I have started writing. I am not 100% done with any of them, and I am still deciding on the order and presentation of each. What I am going to do here is talk about the different blogs I am working on and ask for feedback from the community as to which would be most interesting, which I should finish first, and solicit feedback about which points I might need to elaborate on a bit. So, take a look at the proposed topics and give me some suggestions and ask questions, as they will help me to focus these in a manner that will give you what you need to become better game developers.

Bootstrapping:

not sure where to put this in the mix. I wanted to talk about starting up with next to nothing, and how this approach actually helps a great deal when learning how to be a productive and efficient developer. The processes used when developing games can really be streamlined by developing good habits that are taught by learning how to do a lot with very little. This is a lot of theory and opinion, and it touches all the other topics.. not sure where to stick it into the mix.

Scoping an idea:

this is another tough topic to fit into the mix. I want to suggest ways to determine whether an idea is in scope for the team. The biggest problem with most startup teams is attempting something beyond the scope of what they can do. I want to give my thoughts on why this is, and give some thoughts on how to avoid the common pitfalls that plauge development.

The value proposition:

this one relates to the scoping issue a great deal. One of the reasons people think 'big' is because they think that to provide value it needs to be in a big package. I will provide perspective by presenting information about my purchasing habits, and about what compels me to go from screenshot to download, and what it takes to get me to bust out my credit card. Hopefully this will kick off for some good discussion on the subject and give people some insight so that they might be able to latch onto an idea that does not require a huge team or 100 man years to complete.

Prototyping:

this post will go over how I approach game making. Iterative Prototyping is the key for me. This one will be equal parts software development methodology and opinion on what I think is important in designing a game. I will talk about the approach I like to use which results in very quick iteration cycles and an all inclusive plan of attack for each iteration.

Art Prototyping:

I plan for this one to be filled with images of how I approach creating art for a game. This will have some very practical techniques I use all the time (both on large and small projects) and will tie into the 'scoping' and 'value propostion' blogs. This one will cover some basic design principles of color theory and developing control of the value range in your game so that you can control the presentation of the game design.

Small Design:

this one is another practical presentation that will talk about how to come up with cool supporting ideas for improving game mechanics, increase usability, add entertainment value to the project, and solve the hundreds of design issues that one will confront while working on a game. I also hope to touch on the attitude of having some faith in yourself that you will find solutions to problems you will encounter that you don't yet know exist.

Tool use:

I will use this blog to talk about how I use tools, and what I think is the best approach to learning tools and being creative. This will probably feel like a 'one off' as it won't really relate to the other blogs as well, but may give insight to aspiring artists who want to 'level up' their craft. This one was prompted by the repeated questions I get regarding what sort of tools I use to get the models I make looking good.

Good Graphics:

this will be half rant and half eduacation, as I will speak my thougths on 'good graphics', dispell the myth that greater realism equals greater immersion, touch on the 'uncanny valley', and educate those who are not artists what we were taught in art school about the application of visual design to communicate and reinforce messages.

that is the list of the ones I have already started writing. They range from 20% to 90% complete, and I have a few more ideas I want to add into the mix. If any of these sound particularly appealing to you, please let me know. Also, read my past blog posts, and if there is anything on any of them that you want me to address in more detail, let me know and I will try my best to work it into the mix.

Starting a Studio: Things we did right

Joe Maruschak — 2006-06-11T15:57:26+00:00

As I read the blogs and forum posts here, I am constantly excited by the volume of new projects that are started, and constantly dismayed that the majority of them are hopelessly out of scope and probably will never be completed.

With the hope of getting some of the startup studios and teams on GarageGames headed in the right direction, I am going to talk about some of the thing I think we did right when forming BraveTree and working on our first game, ThinkTanks

The first thing we did right was to be aware of the state of the industry and to recognize our own limitations.

We realized we were nobody and that in order to be 'somebody', we had to create something of value. We had nothing to show. First step for us was to create something to show. Ideas are just ideas if you can't execute. You may be able to talk a good game, but if you don't have something to show, it is all just talk.

We knew that we could make a game, and we knew we could make it fun and compelling, but we also knew that everyone who embarks on making a game thinks the same way.. we can do it better than it has been done before. We needed to prove, to ourselves and others, that we could do it.

We did not go out on a 'funding' expedition that was doomed to failure. We decided to fund and complete the game ourselves. If you have nothing to show, no one is going to give you money to create something to show (unless you are really lucky). There is no free lunch. If you want someone to invest in you (and your team), you need to give them something tangible to invest in.

The second thing we did right was choose a game that we knew we could complete. We started working on our first title, ThinkTanks. When designing the game, we have it very clear in our minds that we should not attempt to make an earth shattering world changing game. We knew we had to pick something that we could keep in scope and that we knew we could finish. We had some clear goals with how we wanted the game to be.. we wanted this to be our calling card (in case we ever went the 'pitch' route).. so, it had to be fun, it had to look professional, and it had to be done.

We set out working, and we made and completed the game. The creation of the game was filled with daily challenges.. what to keep, what to cut.. was it good enough? Our ever crticial nature allowed us to be ruthless with features that were not coming together, and our open minds allowed us to see clearly when something was not good enough and keep on working on it.. (leading to late additions of the game type, scrum, and the addition of AI bots, which were not in the original design).

I am going to try to go into more detail in future blogs, for now, I will just say that we adopted a working style that allowed us to be objective about the game, to look at each feature and assess it's value to the game, and to collectively work to make good decisions about cutting things that were not working and finding the quickest and cheapest way to get needed features completed.

We were very aware that we were good game developers, but we always tried to keep it small and keep it finishable. We were ruthless with features. Every feature in the game was on the 'potential' cut list. Only the best features made the cut. During production, we adopted a style of feature 'un-creep'. If a feature proved problematic or would take too much implementation, it got cut. Only the best features made the cut, and in many ways it focused the game in a very tanglible way. There is a purity and uncomplicated feel to ThinkTanks, and it resonates with the end users.

We knew that 'good enough' was not good enough. We strove to make it the best game we could make with what we had to work with. Everything was scruntinized and reworked and tweaked and polished. When pushed ourselves to make it the best we could.. we pushed ourselves to keep the game in scope and not start adding features that were not at the core of the game. What we went through forced us to be better developers and made us better people.

This brings us to the last thing we did right.. we knew we were developers, and not marketing and sales guys. We learned a great deal about the downloadable software industry, but we realized we were new at it and that there were others that had WAY more experience than us. We had no driving desire to 'own it all'. We were more than willing to hitch our cart to someone else's wagon and give them a piece of the pie in exchange for their expertise in areas that we had zero experience in (and not much desire to learn about).

We showed it to GarageGames, they liked it, and they shipped it on the site (and then talked with us about other ways to distribute it.. with them getting a very fair cut for any business they sent our way).

We knew that by bringing a completed product that all they had to do was sell minimized their risk, and we were very comfortable with being in a position of letting the market decide if our product was successful. No ptiching to publishers, no trying to convince a marketing department it would be a good idea.. users would vote with their money, and they did.. giving us what we needed to keep on going as a company.

That is the quick and clean overview, and I have omitted many of the particulars on purpose for the sake of clarity. In summary form.

1. Make something. If you don't have something, you have nothing to show and nothing to bargain with.

2. When you choose to make something, choose something, that you know you can complete.

3. When you complete something, make it the best thing that you can complete.

4. Be aware of your limitations and be willing to open up to others who have skills that you do not.

hopefully this helps some of you out there. As a end note, if you have not subscribed or read Jeff's blog, you should do so now.

As I mentioned in last weeks blog, I am going to attempt to be writing more blogs to make up for my long quiet spell. Soon I hope to move onto the details of particular approaches to design and production, but I may have a few more of these 'overview' blogs to get some thoughts into the open that will hopefully serve to contextualize my opinions and approach to game design.

You Can Do it!

Joe Maruschak — 2006-06-02T21:37:06+00:00

Sorry for being so quiet for so long. It has been almost a year since I started posting my long rambling blogs, and a lot has happened.

I have been head down working hard on a project I cannot mention, and all of that are Torque Game Builder (formerly T2D) owners are getting the benefit of the GG team eating it's own dog food and making a game with the tools we are making and selling. The stress of production really highlights what is working well and what is not optimal and gives us the clear focus to make the tools better and easier for everyone to use so that you can pursue your dreams.

I actually have a bunch of blogs that I started writing. A lot of the information for my 'blogs I am going to write' arose out of the period of adjustment after the acquisition of BraveTree by GarageGames, and the information I had to share with my 'new' team members about how we work, transferring knowledge we had, learning new things from others in my new work environment.

My 'followup' blogs that I had been working on to expand on the the blogs I have posted before became quite rambling and convoluted, so I decided to start reorganizing my thoughts and writing it all down and presenting it in a cohernet way. I have a bunch of content for upcoming blogs that I have been keeping for quite a while, and hopefully soon I will start getting that information out there.

This blog is a little different. It is a reaction to a thread I was involved with a couple months ago that upset me a bit. I was initially surprised by my strong reaction to what was being posted in the thread, and I took a week or so to cool down and gather my thoughts about it so I could fully understand why the thread touched a nerve. It will hopefully be the start of a resurgence in my blogging, as I have turned the frustration into fuel for my fire.

I am not going to link to the thread in question, as the thread actually just brought to a head some feelings that had been gathering for a while around the GG forums (and they devolved into flame threads). I am going to do my part to try to turn the negativity on it's head and attempt to be inspirational.. to turn the badness into a call to action.

So, the thread in question was actually another one of those infamous 'Engine War' threads. They come and go, TGE vs. <someotherengine>. This one in particular hit close to home, as some had commented that GG products shipping did not count as games when comparing shipped products, and it was implied that BraveTree (my old company) somehow had some special help in shipping ThinkTanks (and that our product did not count either). I have heard this implication before. Some have even stated (and been under the impression) that BraveTree was nothing more than a fictitious shell company that was actually GarageGames trying to make it look like indie companies were succeeding.

It is hurtful to both have the hard work and perseverence of myself and my business partners dismissed do to a incorrect perception, and to have GarageGames made to look as if it is making a product that is not capable of being used to make a game unless someone is speically connected to GarageGames and has 'inside' help.

On both counts, it is upsetting. ThinkTanks made (and continues to make) real money. It was shipped a few years ago and it still has a devoted following and has more than made back what was put into it. It was made with the TGE, and this was done by a small team (3 guys mainly), with a total of 18 man months (6 months for each of us over the span of a year), with one coder and two artist/designers.. It was done before all the engine improvements of the last few years were available, and back when there was next to no documentation. This is a testament to the underlying quality of the engine being robust enough to enable us to do what we did, with such a small team, in such a short time.

It minimizes the effort and sacrifice we at Bravetree put into the game and our company. We were extremely motivated and focused, and we were not going to let anything stand in our way.

It insults the founders of GG (Jeff, Tim, Mark and Rick) for going out of their way NOT to pry in our business more than we felt comfortable with. In terms of respect for us (BraveTree) doing our own thing, they went out of their way to give us our distance, and were there for advice and to help out on the business end of things when we asked for it. I respect that they let us do our own thing, and grab our own little piece of the American Dream.

In terms of monetary help.. from GarageGames, we never asked for any, and never recieved any. Had they footed the bill for ThinkTanks, I do not think I would be as proud of what we built at BraveTree as I am today. We did it, and we did it ourselves, and that is something that no one can ever take away from us.

What GarageGames did offer us was something much more valuable than money.. Honest advice, good feedback, and no bullshit. Jeff always tells it like it is. Did we get help from GarageGames? yes, but it is same help anyone can get if they read Jeff's blogs and take what he is saying to heart.

And this brings me back around to the thread that prompted this blog in the first place. When reading the thread, I got the impression that some here are skeptical about the state of the tools and the technology, the documentation, and the support, and that it would somehow stand in the way of creating and shipping a game. This perception hurts, as GarageGames is doing all that it can to enable YOU to realize your dreams. We may not be doing it in a way that everyone agrees with, or at a speed that everyone feels comfortable with, but we are doing it, and the number of shipped titles with Torque based technology are proof that nothing is standing in the way of anyone shipping a game with the tools in their current state.

If an individual cannot get a product to the shipping state, or cannot begin their project because of some perceived 'lack' of tools or documentation or funding or <insert gripe here>, then that person needs to take a look in the mirror.

We work hard to enable people to be part of a movement that is changing the gaming industry for the better. We take it seriously. We can only go so far toward making an individual dream become a reality. We are working to make it even better than it is now, better tools, improvements to the tech, better documentation.. we will never stop to say the tools and tech are 'good enough'... but we cannot do everything for everyone. At some point, those who undertake a project need to take responsibility for what they are attempting and do what it takes to get it done. Not all those who start a project will get it finished, and the blame for it should not be deflected onto us for not attempting to do enough.

This is not to say that we are not looking to improve the tools and tech we are using and creating, we are in fact working very hard on making these tools the best they can be. My dream is to be able to go toe to toe with the 'big boys' for a tenth of the cost. I know that we can do it.. that we can make games of the same quality in a fraction of the time, with a smaller more focused team. The technology we are working on is that enabler.

Again, I don't mean to sound as if I am admonishing people, my hope is not to beat down, but to light a fire.

If there is any doubt that it can be done.. We did it. We created a game, with 3 guys, and no funding. We shipped it, and we used it as the cornerstone of a business that we grew and eventually sold.

We used the TGE, and we did it 3 years ago.

We were smart in terms of what we chose to create, and how we went about. We did it. Anyone reading this can do it too. Andy Shatz did it. Josh Ritter did it. 21-6 did it. MaxGaming did it.

You can do it too. This is not to say that you will do it, but the opportunity is there, and the tools are there and more than adequate.

Joe

as a footnote, I have some things planned to blog about, but I work better with a clear focus on a specific issue. If anyone has any questions about how we did what we did, in terms of developing our products, working remotely with people, how to survive while bootstrapping a business, specifics on my views on game design, ask them here and I will try to address them.

The importance of theme

Joe Maruschak — 2005-09-05T16:55:52+00:00

So in this blog entry, I will seemingly become a hypocrite and state that while I think story is mostly irrelevant to game design, I think theme and setting are incredibly important to game design, perhaps so much so that they are at the very heart of what we do.

In my last blog, I talked a little about story, and the discussion that followed brought up some points related to the story being important. I actually think that the individuals who posted 'pro' story are not actually pro story put pro structure.

A story can give structure to a piece of entertaniment. But in a visual and interactive medium, it is not the only thing that can give structure, and in my opinion, one of the least effective ways to give structure to a game. A strong theme and attention to the setting gives structure to the experience, and I think this is where designers should be focusing their energies.

So where does this opinion of mine come from? Well.. school mostly. My education as an artist has taught me that people respond to visual design in ways that can be controlled and expected. One can manipulate the visual components of an image (or film, or webiste, etc..) to bring out certain associations and emotions. There is not some magic to making art for the purposes of communication. It is more of science with 'do's' and 'don'ts' that can be controlled.

In terms of controlling an experience itself, in order to learn more about it, I looked to architecture. I read a really good (long) book called A Pattern Language. A wonderfully wordy book, I talks about how humans interact with their environment and gives examples and exposes design patterns which one can use to create livable spaces that humans will respond to positively.

Understanding how people act and react is far more valuable to the medium of interactive design (in my opinion) than the ability to tell a story or understand story structure (which I also recommend). If one can have command of how to design 'something' so that they can have control of the interaction, they will, in my opinion, make better games than those that focus upon the very heavy handed approach of using story to control the experience.

This leads me to themes. the theme of a game, is to me, incredibly important. The background and setting of the game can communicate to me a great deal of information. A theme for a game can get the game player to bring to the table their experience and expectations and make the process of getting them to immerse themselves in a game that much easier.

This is a two way street. Setting up a theme or setting that violates expectations can damage the game. In order to successfully create a theme, one needs to be aware of pop culture and historical representations of certain experiences and use these to craft an experience that builds on those expectations. I see 'Schindlers List' - 'Saving Private Ryan' - Band of Brothers' as the most successful set of films to add to the canon of visual style. The cinematography or each has now become ingrained in the populace of what is the 'definitive' war movie experience (note that these built upon the groundwork laid by Aopcalypse Now'

Science Fiction has a great number of 'cliche' thematic devices. I hate calling them cliche, as what they are is a common shared set of expectations of what 'sci'fi' is. I used some of these in thinktanks. The idea of aliens stealing brains and putting them in war tanks is a sci- fi 'standard'. I used the convention to poke fun at (and pay homage to) the genre in a whimsical way. In some ways, it was an easy way to inject soul into a small shooter. It adds to the game, and does it in a way that adds to the experience without placing artifical contraints on it.

anyway.. hopefully this will help to clarify some of my views on story and theme and how they relate to game design.

More next time. If anyone wants me to devote a blog to anything specific in relation to the experiences I have had, please let me know. I know I have not delivered on my promise to outline some of the more useful techniques I try to use.. so help me to refocus these blogs into something that might be more useful in a practical way as I am starting to depart a little too much into theory.

More Musings on Game Design

Joe Maruschak — 2005-08-18T05:52:42+00:00

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.

Ramblings on Game Design

Joe Maruschak — 2005-06-20T04:52:30+00:00

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.