by date
Starting a Studio: Things we did right
Starting a Studio: Things we did right
| Name: | Joe Maruschak |  |
|---|---|---|
| Date Posted: | Jun 11, 2006 | |
| Rating: |  5.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Joe Maruschak |
Blog post
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.
Recent Blog Posts
| List: | 11/07/06 - Focusing development by way of bootstrapping 10/20/06 - New Human 2.0 09/30/06 - The Finish Line 09/03/06 - Value of a Thing 06/18/06 - The shape of things to come 06/11/06 - Starting a Studio: Things we did right 06/02/06 - You Can Do it! 09/05/05 - The importance of theme |
|---|
Submit your own resources!| Adam deGrandis (Jun 11, 2006 at 16:11 GMT) |
| Aaron Ellis (Jun 11, 2006 at 16:17 GMT) |
| William Lee Sims (Jun 11, 2006 at 16:44 GMT) Resource Rating: 5 |
In ThinkTanks, how did you decide if a feature was necessary or not? A lot of times I have a vision of how things should work, and then I will spend many hours trying to get it in. I will feel that it is vital to my vision, but now I wonder if I should re-think my plan in those cases. How did you decide if a feature was vital to a vision or just some unnecessary aspect of game play?
| Joe Maruschak (Jun 11, 2006 at 16:59 GMT) Resource Rating: 5 |
we test and prototype a lot. The idea is to ask a question (is this feature essential), implement it in the most time/cost effective way in order to test (this can be in code, on paper, in your head).. and then test it.
An example, in ThinkTanks, we had damge on a per part basis as part of the design. We implemented a simple version of this, but the first playtests demonstrated to us that the part based damage was not really working. Just catching and hitting an opponent was hard enough, and knowing that my tank was damaged on the say, left tread, would add to the interface (there was no clear way to comminicate the damage to the player) and complicate the game. It was a good idea, but the actual testing of the game showed that it was not as compelling as we thought it would be given the cost of implementation. Luckily, we did not go far down that path before we 'un-creeped' that feature.
the way we did it was constant iterative prototyping. We implement a prototype of any feature, and then test it. Based on the test, we decide if we need to work more on the feature, change the feature, or cut the feature.
the way I think about it is, I think of a goal I want in the game.. I think up a feature that I think will help acheive that goal. the feature is implemented. Does it do what was intended? if yes, great. If no, were my assumptions correct? is it not the right solution for the problem? does the feature need more work?
if it needs more work, then the decision has to be made. Is the feature so important as to incur the cost of implementation?
in my head, I keep a heirarchy of needs for the player. First and foremost, whatever the player is controlling needs to be, in and of itself, compelling to interact with. If this means we have to add some animation effect to make it more compelling.. then we work on that and playtest until it passes muster.
I place a higher priority on this then say, AI, at least in the early stages, as if the game sucks to interact with, the player will not play it long enough to notice how smart the AI is.
what takes priority and what is important is totally dependent on the game and the experience one is trying to craft, so I hesitate to throw anything out there other than some generalizations.
I am working on a blog that will address some of the particulars of how I think about it, but it will take a while to formulate it into a coherent presentation, as it is part 'art', and part development methodology..
the concept of feature un-creep though is just to be in a mode of constant questioning. Ideas don't always work.. so you have to try stuff. If a feature is not working, you have to be open enough to ask, why is it not working? is the idea bad? is the implementation wrong? is the problem we are trying to solve the wrong problem. Trusting that the idea is good and that the feature in question absolutely MUST be in the game as designed is the biggest downfall of developers, in my opinion.
Edited on Jun 11, 2006 17:03 GMT
| Tom Bentz (Jun 11, 2006 at 18:11 GMT) Resource Rating: 5 |
| The Littlest Dragon (Jun 11, 2006 at 20:15 GMT) |
| Eric Elwell (Jun 11, 2006 at 21:12 GMT) Resource Rating: 5 |
| Prairie Games (Jun 11, 2006 at 21:36 GMT) Resource Rating: 5 |
I hope you'll also post an evaluation of things Bravetree did "wrong" and why it had such a short run.
| Paul Jan (Jun 12, 2006 at 02:03 GMT) |
| Joe Maruschak (Jun 12, 2006 at 02:06 GMT) Resource Rating: 5 |
saving the things we did wrong for the 'things to avoid' blog. That one is tougher, as I think we did ok when we focused. Most of what we did wrong I can group into the 'other' category.. things that deflected our focus from development of our own products.
We did have a few issues with spreading ourselves too thin, and some of this was taking on some low pay contract work with the promise of more when the people we were doing contract for secured funding. This lead to a 'chasing the carrot' syndrome where we were being asked to do 'just a bit more'. We also had some members leave early on that led to a lot of time spent on legal and contractual issues.
the short run of BraveTree (4 years actually) had more to do with the fact that we had made it. We had achieved a level of stability where it was not a question of 'if' we would survive, but in what form, and how fast we wanted to grow. I was spending a good half of my time on the phone (bizdev) and clark was spending at least a third of his time on the books and other operational stuff. We were bringing on people, and we were not developing anymore.. we were running a business. When GarageGames offered to purchase us, it was a situation where we would be doing pretty much the same thing, but we would not have to spend large portions of our time running the day to day.
The start up time of learning to run the business was quite fun. The day to day of running a business got old quickly (for me) after we were more or less stable.
Doing it all over again, I think I would have changed some things.. the one thing I would do would have been to eliminate everything else but development on our own stuff in the early stages.
Knowing what I know now, I think I might have made some different decisions along the way, but, I think we did ok.
on a side note about one small thing. every product you make, make sure it is set up to localize into foreign languages. It must be some sort of strange law of the universe that you will end up having to do localization work on the things that you never planned to localize (or had taken steps to ensure ease of localization).
this hard lesson was driven home yet again after a few days of reworking a GUI that had burned in text.. in english, on a patterned gradient background, saved as heavily compressed JPEGs, with no photoshop source to be found.
another small tidbit is don't try to save money by being stingy about your domain registration costs.. as you might have your website go down at the worst time.
The list of small stuff like that is actually quite long. The list of the big 'don'ts' is short. Someday I will write down all the small ones in what I hope to be a humorous blog post.
| Prairie Games (Jun 12, 2006 at 07:51 GMT) Resource Rating: 5 |
Thanks for sharing... There are precious few good examples in this industry.
| Martin Schultz (Jun 12, 2006 at 08:11 GMT) |
| Tyler Frans (Jun 12, 2006 at 17:22 GMT) |
You must be a member and be logged in to either append comments or rate this resource.
