GBGames

There are a lot of conflicting thoughts in my head about how I want to approach my efforts at creating games. Some of these conflicts are from seemingly contradictory pieces of advice I’ve received over the years, and some are just related to fear, uncertainty, and doubt due to inexperience.

On the one hand, I want to be prolific.

I want to quickly get a minimum viable product out there in the hands of customers, get their feedback, and similarly very quickly make an informed decision to either tweak the existing game or abandon it for a completely different project. If I can do this quickly enough, I have more chances to earn enough money to make these efforts sustainable.

On the other hand, I don’t want to put out junk. I don’t want to release half-finished ideas, non-workable games, or projects that aren’t anywhere near ready. I want the projects to have a chance, and in order to be proud of what I put out, I need to finish my games.

But on the third hand, I don’t want to work on my project forever, constantly tweaking, adding, and removing inconsequential features. You might call it “feature creep,” but I don’t think that name really describes the issue I’m worried about. It’s more like being so afraid of pulling the trigger that you distract yourself into thinking there’s more development work to do to avoid thinking about the hard work of actually releasing the game to the public.

There’s always unimplemented features and more balancing work that could be done in a game, right? As a developer, I KNOW how to do that kind of stuff. It’s easy to stay in the comfort zone of being the technician.

And when you work by yourself, it’s easy to forget to take off your Developer’s hat, put on your Producer’s hat, and think about deadlines and what work is optional versus what work is core to what your game needs. You need to ship.

On the fourth hand, I will become a better game developer if I work on more games more often. There’s that story from Art & Fear by David Bayles and Ted Orland about the ceramics teacher who split his class into two groups. One group was graded on the quality of a single pot on the last day of class, and the other group was graded on the quantity of pots produced by the last day of class.

It turned out that the group that produced the higher quality pots was the group graded on quantity, mainly because the experience of creating each pot also gave them insights into how to make the next pot better. Meanwhile the quality group spent more time merely thinking about how to make a quality piece of pottery, and when it came time to actually put in the work, they were not necessarily up to the task.

So, if I focus on making more games more often, I’ll make better and better games.

Of course, on the fifth hand, I don’t want to make throwaway entertainment that people pay little or no money for and pay little or no attention to. I want my games to have meat on their bones. I want my games to be the kinds of games I’d play.

On the sixth hand, I am not my customers, and I need to make sure I create games with a target audience in mind. I should find out what THEY want to play.

On the seventh hand, I’m creating these games, and the message these games put out reflects what I want to see in the world. I own my art, and they’re not “just games.”

On the eighth hand, I’m not working on games in a vacuum. There are other games being made by other developers, and I should make sure to spend some time playing those games.

I should research other implementations, see what other developers have tried, learn what works and what doesn’t, all without spending the effort myself.

I should listen to podcasts, watch presentations online, and read blogs more regularly.

I can leverage the experience of other people.

On the ninth hand, I’m a part-time indie game developer. There’s only so many hours in a day that I dedicate to being a game developer, and if I spend it playing other people’s games and watching other people talk about how they do their work, I won’t have time to do my own work and put out my own games. I barely participate in online forums anymore, and I finally understand all of those people who complained about the lack of time to participate in forums. Where does anyone in my position find the time?

There’s a difference between doing and learning how to do, and there is always more to learn.

There’s also always more to do, and doing is the hard part.

On the tenth hand, I hate that I’m ill-informed about what’s going on in the world of games and their development. I was blown away to learn that multiple people were making virtual reality games for the most recent Ludum Dare 48-hour game development competition, as it sounds like the kind of thing that still requires a huge upfront investment. Clearly I’m out of the loop.

On the eleventh hand, I’m an indie game developer, which means I define my own rules of engagement.

It’s not a race, despite the realities of opportunity costs and trends, and despite the realities of impending life events that change everything.

Success isn’t defined by money but by accomplishing goals, despite the fact that earning a significant income from this effort would be a great side-effect of those goals being accomplished, one that could help me set and achieve bigger and better goals. Money isn’t a goal, but it can be a measure of progress. But it also doesn’t have to be.

When you’re starting out, you look to people who already know what they are doing to provide some guidance. And they are often more than willing and able to share what they think works.

But in the end, it’s easy to get stressed out about meeting someone else’s expectations if you don’t take care to set your own expectations.

I’ve had people tell me what I should do and what I shouldn’t do. I’ve had people question decisions I made and ask why I didn’t make a better decision on a choice I didn’t know I had.

There is no wrong or right way to go about this process, though.

Some people swear by putting out prototypes daily. Others like to work in secret for months or years at a time.

Some people like to explore one game mechanic fully, and others like to experiment with lots of different concepts.

Some people like to put out fully formed games to be consumed, and others like to release early development builds for people to nibble on.

Some people throw spaghetti at a wall to see what sticks, and other people like to plan out an entire evening with a multiple course gourmet meal.

If I use the same criteria for the spaghetti-thrower’s efforts that EA uses for their heavily-invested and marketed blockbusters, it’s going to look like a lot of failures and flops are being thrown at a wall. That’s not the way to make a blockbuster hit!

But the spaghetti-thrower has different goals entirely. They’re not trying to put out blockbuster hits. They might not even be trying to make something commercially. They’re trying to gauge interest in prototypes, seeing if there is a significant amount of interest in something before putting a lot of time, effort, blood, sweat, and tears into a more substantial work.

Following EA’s playbook is probably not going to help them achieve their goal. They’ll probably stress out way too much to be useful if they somehow get it in their head that EA has the truth about How Games Are Made(tm) and that they are not following it.

While other people might have great advice for their own expectations of how things work, it’s a lot less stressful (although still pretty stressful) if you politely ignore them and create your own expectations. You have enough to worry about without second-guessing if you didn’t make games similar enough to how some celebrity game developer did.

It’s fine to seek out and get advice, and it can all be really great advice, but don’t forget to make your own path.

I like building my games with my own tech.

There was a game jam in which I used Stencyl, but otherwise, all of my projects have been based on my own hand-coded C++ with libSDL. I spent time figuring out how to write a basic game loop, how to design my software architecture, how to create simple buttons to interface with, and more.

It’s time I could have been spending designing games rather than implementing them. I know this fact.

And yet, I persist.

Over the years, I’ve been told to switch to Flash, or use an engine like Torque 2D or Unity. When XNA was released, I remember wondering if C# was going to become the dominant programming language in game development.

But my C++ game engine is still with me, and still relevant. Granted, it’s not as full-featured as some systems, and the asset pipeline is still a manual effort. But what it does feature is well-tested, and I know how it works.

There’s something about learning how to build it from scratch that makes development more enjoyable. My A* pathfinding algorithm might make oddly suboptimal paths, but learning how the algorithm works and figuring out how to implement it was a fantastic experience.

As you can see from this 2010 development shot of what ultimately became Stop That Hero!, the AI hero should have followed something like that yellow line rather than the path it actually took.

It’s sort of like doing my own home repairs. There are some things I’ll leave to well-paid experts, but other things shouldn’t be too difficult to do. For instance, replacing the toilet’s fill valve and flapper took a small trip to the hardware store to get a replacement part and then a few minutes of work.

A bigger project I finished recently involved putting lockable doors on shelves we have in the basement. My wife and I are getting licensed to become foster parents, and part of the requirements for our home’s safety include keeping flammable materials such as paint in a locked storage area.

Rather than buy a big expensive cabinet, I thought, “We already have these wooden shelves in the basement. How hard could it be to put up a piece of wood with some hinges and a padlock?”

I measured the area I needed to cover. I bought the wood and had the guy at the store cut it for me as I didn’t own a power saw myself. I learned the screws for the hinges were longer than the wood was deep, and I found that you could get 1x4s to frame the wood to make it look nice while also giving the door the thickness needed for those screws.

In the end, the doors looked nice enough and were functional, although they are not perfectly centered, as you can see. It turned out that the dimensions I measured didn’t take into account parts of the shelf protruding in ways that would prevent the doors from fitting perfectly. The good news is that they look homemade. B-)

Now, it took some time. I had to go to the hardware store a couple of times to get all of the materials, and I had to spend time on it when I could have been doing something more important, like working on finishing my game before we have foster children in the house. Did this time and effort translate into a better return on investment than the $90 cabinet I thought we could avoid buying?

No. In fact, we probably overspent on the wood and other materials for other projects.

But there are some benefits to having done it myself.

One, I learned 1x4s are not actually 1 inch by 4 inches. I never knew this fact, but when you buy wood, you need to expect your 1x4s will be 0.75 inches by 3.5 inches. It’s about how the wood is when it is cut and rough versus when it is dry, planed, and made ready for sale. It’s just one of those things that I now know for future projects. Luckily, the screws I had to attach the 1×4 to the plywood weren’t too long, but that could have been another trip to the hardware store since I was expecting the nominal dimensions to be the actual dimensions.

Two, I discovered that I can improvise a carpentry job. I had not made plans, yet I was able to put together some decent looking doors. When I ran into trouble, such as finding out that the doors wouldn’t fit where I expected them, I was able to shift them to different parts of the existing shelf and keep going. I could easily have given up when I found out that the doors were just a little too big, but I made it work. If I was doing kitchen cabinetry, I would have been more careful, but this project was more about the functionality than the aesthetics.

Three, I have the pride of saying, “I built that myself.” There’s nothing like that feeling.

My game development efforts might result in projects that are somewhat askew like my basement shelf doors are. It might take me longer. The end result might be less than what I could have gotten had I leveraged someone else’s efforts.

I know.

But I am a much stronger developer than I was in the past mostly because of all of the from-scratch efforts I have put in. I did the research myself. I explored from first principles rather than taking the shortcut of an existing path. I understand the trade-offs involved in design decisions rather than accepting decisions made for me.

And in the end, when I release a game, I can say proudly, “I built that myself.”

It won’t likely be important to my customers. And it won’t likely be important to you. But as an indie game developer, I don’t have to pay attention to your criteria for what’s the best approach.

I can build it myself, a process I enjoy.

And next time, I will be more experienced and knowledgeable than I was before.