Your Idea Is Too Big

This is a post duplicated from the Digitanks website.

Before we go into why your idea is too big, let’s first take a moment to smell the roses and listen to the birds singing, the wind blowing, and the sound of tanks blowing up, because I just added the first slew of audio sound effects to Digitanks.

This video also features a composition by Jack Menhorn, who is not only a swell guy but a great composer. And now back to our previously scheduled article.

In my years before becoming a professional game developer, I spent a lot of time doing contracting for local companies. I was basically a gun for hire. I would come in, solve a company’s problem, get paid and take my victories to the bank. It made me some decent money (while the economy was still good) and afforded me a lot of free time to pursue my hobbies, like game development. One of my largest clients was a man who owned a small company that sold a software toolkit. We’ll call him John. John’s tool was a pretty good tool, and John made most of his money by supporting his tool and bringing in contracts to develop his client’s applications that use that tool. It made a good living for John, and I learned a good deal about software development from my time with him.

Only problem is, John’s eyes were much bigger than his mouth. Every time his client asked him to make a modification to their products, John would get very excited and ideas would start spewing. He would look at the moon. I can’t say John is alone there, I’ve worked with a lot of people like that. In fact I have to give him credit for that, because his big talking gave him the ability to pull in a lot of clients. It’s how he makes his living, and he’s very skilled at that. When it came to planning the actual work, he would plan a himself mountain. Problem was, John was just one guy, but he’d assess that mountain to be the size of a molehill, and he’d plan his time accordingly. It made for many deadline slips and upset clients. He’d also go out and buy lots of equipment for the work, which turned out to not be necessary later.

John was a great guy who did his job well and I learned a lot from his advice. I also learned a lot from his mistakes. One of John’s vital mistakes, and the reason I eventually stopped working for him, was that his shoes were too big.

Smaller shoes make for lighter walking

I’m a credits person. I like to see all of the people who were involved in the production of a piece of entertainment. It also gives me an insight into who’s who in the industry. I sat through the entire list of credits in Avatar, after the entire theater was empty save me and my friends. I learned about Danny Elfman because I recognized his name from the credits of multiple movies that I had seen. I learned who David Jaffe is because I saw his name in one of my favorite games, God of War. In God of War 3, I stared, mouth agape, at the list of credits that seemed to run forever, including all of the outsourcing third-party development houses. It’s become increasingly difficult to retain a mental list of important people when the credits list runs for fifteen minutes. Sony can afford to have a credits list that long though, they have the wallet to foot the bill. Fact of the matter is, Sony has big shoes.

While that credits list was running, I thought about the team that I was working with at the time. It was a seven-person team. I wasn’t even paying any of them. 

three-tanks

Well I think Guy Kawasaki is wrong. It’s easy for him to say that kind of thing because he’s famous and it sounds good. Guy Kawasaki has big shoes. His thinking works very well when you have a multi-million dollar budget and dozens of people on your team. It doesn’t work very well when it’s just yours truly. One person can’t possibly hope to reach to a place where these millions of dollars and hundred-man teams haven’t reached already. Can they?

I’m not saying to think small. A person should think big. But more importantly, a small developer with a small team should realize that they have these limitations. But you can turn these limitations to your advantage. When our medium was small, games were largely created because of the physical constraints of the medium, which forced people to be creative. Mario is a plumber in red overalls because that was the easiest way to convey his character. Final Fantasy developed its turn-based battle system because that was the easiest way to program battles on a Famicom. In modern times we no longer have these limitations, but if we impose them again on ourselves, we can find creative ways to lighten our workload.

In Digitanks, my tanks hover around because I don’t want to animate tank treads and I don’t want to codify the tank-ground collision mechanisms. My terrain is randomly and procedurally generated so that I don’t have to spend time making the tools for level development. My visual style is a simple Tron-like theme so that I can just make things glowy and they’ll look good, and I no longer have to worry about realism or high visual fidelity. I’ve cut so many corners, but in being creative I’ve reduced my workload without sacrificing the quality of the game.

This is the classic tradeoff that every manager is taught: Cost, speed, qualities — pick two. 

time-cost-qualities

Moral of the story: Use your small size to your advantage.

Smaller smaller smaller

I think it’s important to quantify that “qualities” in this case isn’t the same thing as quality. It’s not a “Degree or grade of excellence” as the answers.com dictionary defines it. Rather, it’s the scope of the project. The scope combines both quality and quantity, and all other things being the same, you can’t add more of one without taking away from the other. You can make an expansive world with huge mountains and valleys and plains that stretch forever, but you’ll pay for that quantity with terrible quality. Your mountains and valleys will be more like molehills and ditches, with the same grass sprite in every square mile because that’s all you had the budget for. Or, you can focus on one square meter of land in its most qualitative detail. You can make that one square meter of land damn good-looking in the time you have, but it’s still only one square meter.

The key to indie games is understanding what you can cut out in quantity to leave as much room as possible for quality. How much can you reduce the scope of your project so that you can increase the quality? I’ve spent countless hours pouring over my project plan, finding things that I can cut out. It doesn’t matter what you are trying to do, there’s always a way to make your game smaller.

If you read any advice to indie gamers you’ve heard this said before, but this time you’ll hear it and it’ll have new meaning: Find one thing that makes your game fun and iterate on it. The reason people say this is because indie developers can’t afford to find ten things that make a game fun, like the AAA studios do. Focusing on your one fun element and making that as nice as possible is the best way to get the most bang for buck out of only a little bit of input work. Whatever is superfluous in your design, take the opportunity to cut it out. You’ll reach your goal sooner, and your overall quality will increase, because the remaining features of your game will be more polished. The best way to do that is to make your work smaller.

Moral of the story: It can always be smaller.

Baby steps

A good friend of mine once endeavored to start a web comic. He used his deployment pay from the armed services to invest in this new venture. You may not know this if you’re not close to someone who’s spent time in the military, but those people make bank, as they put it. 

len-cropped

I have to admit that I’ve fallen victim to this kind of thinking before. It’s easy to say, “I’ll buy this expensive equipment now because it’ll let me make a lot of money later.” Well, it doesn’t really work that way, because now you have a business plan that involves spending a lot of money up front in exchange for a questionable future revenue stream. That works for CEO’s and VC investors (sometimes) not for indie game developers. For little people like us, it results in us losing our hats after we’ve spent ourselves into oblivion, and it’s a well known fact that any plan where you lose your hat is a bad plan.

Now I have a better plan: Don’t spend any money until you are making money. Not only does this rule prevent me from spending money on things that I really don’t need, it also forces me to think more critically about how to monetize my ventures. It helps me figure out how to reduce the amount of effort and time it takes to reach a monetary goal. In my mind, you really can’t make those steps small enough. The smaller your steps are, the easier they are to enact, the more celebrating you get to do for achieving your goals, and the faster you get to where you’re really going. Every problem can be broken up into a number of smaller steps which can be taken one at a time, and each of those smaller steps can be broken up into individual tasks. Does your plan to make money involve not getting paid for 9 months? Well, that’s too long. Let’s think of a new plan that makes money in six months. Then let’s take that plan, cut out some of the more complicated things, reduce the scope, and make it work in four months. Now that sounds like a better plan.

Moral of the story: You have to crawl before you can walk.

Stand on the shoulders of giants

Here’s the list of libraries that I use in Digitanks:

OpenGL
freeglut
freetype
DevIL (image loading)
ftgl (text rendering)
glew
pthreads (multithreading)
SDL_mixer (sound – as of this week!)
glgui (internal – my opengl UI library)
common (internal – common functions shared by all my projects)
raytracer (internal)
modelconverter (internal – loads models)

Part of the reason I’ve been able to get Digitanks to the point it is so fast is that I used all of these libraries that I had lying around from previous projects. I didn’t have to write a single one of these functions by myself. My new sound engine took me all of an hour or two to write, since SDL_mixer did all of the hard work.

Here’s a list of freesound.org authors whose work I sampled for my sound effects:

AlienXXX, batchku, Chris Weaver, cognito_perceptu, CosmicD, daveincamas, dkristian, Halleck, HardPCM, HerbertBoland, ingej, ingeos, Koops, koostix, Lunardrive, Matias.Reccius, melack, metamorphmuses, Microscopia, Nbs Dark, Ohrwurm, Percy_Duke, PhreaKsAccount, ReWired, rutgermuller, sandyrb, Syna_Max, swelk, timlaroche, themfish, volivieri, 833_45

You think I’m about to go out and record all of those samples by myself? Hell no! I’m giving them all attribution in my game’s credits of course, because they saved me a huge amount of time. In two days I added 9 high quality sound effects to my project, plus all of the supporting code. I can work at that kind of pace because I’ve managed to use the resources of others to my benefit.

Moral of the story: I need to play Shadow of the Colossus again.

Well I suppose I should wrap this up. As always, please tell me your thoughts, I’d love to hear what you think and how this article has helped you.