Game designers pride themselves on dreaming. They come up with unique, fun, and sometimes crazy game concepts, innovative gameplay mechanics, and engrossing stories. But a game designer has a lot more to do with the game than just dreaming. The designer also has to steer the project from concept to completion by coordinating the efforts of the development team towards the realization of the game design.

But a game designer can’t design in a vacuum. Well, you could, but you’d die in a very spectacular yet silent manner. A designer needs to keep in mind the size and strength of his development team and the limitations that they’ll face when he chooses a concept to turn into a design. If you design elements that are vital to the game that your team is not able to produce, the house might fall apart.

Oh crap, I didn’t set up that metaphor right. You see, the game is the house, right? And the ambitious elements of your design… those are load-bearing walls. Now, cutting out some gameplay elements for time, budget, or technical reasons is quite common in the average game’s development. But that’s like removing a window or a carpet. If you get deep into the development of your house, err… game, and you find that one of the ambitious central gameplay elements just isn’t going to happen for whatever reason, the game may just have lost the one thing that set it apart from the crowd, or worse: become un-fun. In effect, the house has collapsed.

So, these various restrictions and limitations are placed on the game’s design before a single line of code is even written. Of course, these limitations vary depending on the capabilities of the development team.

A major developer like EA is going to run into two main limitations: technical limitations and time limitations. Technical because some things just aren’t possible yet, like true AI or whatever the upper polygon limit we’ve reached is. And time because they are a business and the powers that be want that game out the door ON SCHEDULE. Other than that, the sky is the limit for major developers. Whether or not they reach said sky is a different question.

The restrictions for an independent developer will be completely different. The technical limitations will be much more harsh. An indy developer usually doesn’t have the programming libraries and experts that a major developer will have. The budget constraints will be steep as well. Less money leads to more restrictions: less time, smaller team, etc. Working within these restrictions will be a much larger challenge.

Going another step down, you find me… as well as hundreds of other hobbyists. We’re working with a budget of zero, a tiny team (in my case: one person), and little expertise or experience. For this reason, we often choose to opt for existing game engines. I use AGS because it’s easy, free, and remarkably flexible. However, these engines come with their own limitations. AGS doesn’t natively support 3D, but I don’t mind because my art team (me) is not so advanced in 3D. AGS also uses a slow art library and has a number of limitations that stem from that. When I made Anna, I had to think long and hard about workarounds for these limitations to get the effects I was aiming for. All of these limitations really add up for the game-making hobbyist. So why even try?

Well, for one, it’s fun. When I was working around AGS’s limitations during the creation of Anna, I was really enjoying the puzzle that had been set out in front of me. Similarly, in the game that I’m making now, I’m trying to do all kinds of weird things that the engine isn’t meant to do. It’s a lot of fun for me, as a mathematician and computer scientist to tackle these problems.

And for two, being a hobbyist provides several advantages that indie developers and major developers don’t have. Time, for example. A game company, big or small, is working to release the game as quickly as possibly to speed up the profit. A hobbyist is under no time constraints except for the ones we place on ourselves. This makes for a much lower stress development period, even if it does promote procrastination. (guilty!) Another advantage of being a hobbyist is being able to work on the project that you want, not the project that your customers want. Unlike a non-fake game company, I’m not selling my games. This means that I don’t have a responsibility to anyone. If you don’t like my game, screw you! No need to worry about customer service or returns by unsatisfied players. I don’t have to make a boring Sudoku clone just because that’s what I think will make money… I can work on something unique and innovative without worrying about going broke if it ends up not being terribly fun or popular.

These advantages make it fun to be an amateur developer. But the technical and artistic restrictions and limitations are still there breathing down my neck and the necks of most other hobbyists out there. And just like a designer at a major development house, I have to be able to identify and avoid these limitations (or really push up against them where appropriate) when designing my games.

Being able capably handle these limitations while designing a game and leading a team is as important as, if not more important than, dreaming up those unique and fun concepts.

This entry was posted on Tuesday, July 18th, 2006 at 4:53 pm and is filed under Game Design. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.