« Music preview! | Main | Adding Character »
Monday
Jun202011

What's in a game?

The era of the highend homemade is here. Computer hardware has become relatively inexpensive for insane amounts of processing power. Development tools of all types have become affordable and approachable. I'm making games today because the amazing folks at Unity created the game development tool of my dreams.

So what does it take to make a game? There is a lot of information out there comparing different game development tools, art packages and scripting languages but I want to speak to the one thing that is constant regardless of the hardware or software you have access to. All it takes to make a game is work.

Never created a game before? Jump in! It doesn't matter how big or small or whether you complete it or not, you will learn by doing. That's it. There is no magic ingredient. Just put the time in and eventually you will end up with a game.

Here are some numbers and stats that while not vitally important will give you an idea of what has gone into making this particular game so far.

I've been working on Catapult for Hire on and off for a little over a year and a half and have put in over 2600 hours of work (I only started recording my hours in February 2010). As far as code there are currently 517 Unityscript files with 23131 lines of code.

In Jon Blow's recent talk on "How to program independent games" he showed that his game Braid came in at 116204 lines of code which makes my codebase seem pretty paltry though it's hard to compare as every game is different. AAA games can weigh in at millions of lines. You can't compare languages and coding styles either. Braid was mostly written in C++ and I tend to keep my code pretty vertically compact. Brackets on the same line for the win!

Catapult for Hire currently has nearly 1500 art assets. This includes 3d models, textures and animations. This number doesn't include "Work in Progress" stuff that hasn't been implemented in the game yet. That may not seem like a lot but I'll never forget all the polygon pushing, brush stroking and keyframing.

Artistic endeavors of any kind can be brutal. When you're first starting out on something new there is optimism everywhere. People will look at what you're doing with excitement for what it will become. Then as you continue to pour your heart and soul into the project you start questioning and doubting yourself and even your sanity. That's the point where you need more community feedback for a reality check. That is of course when trolls start to come out from their internet hiding places. Now that the project is more clearly defined people stop looking at it with optimism for what it will become but they judge it for what it's not.

Competing for fame and gold in the Colosseum

Along with the fear and self-loathing, some developers can have trouble finishing larger projects because the prototyping phase can be so much fun. Working on a single project for a long period of time can burn you out whether the trolls have revealed themselves or not. One thing that helps for me is using an iterative approach. I'm a big fan of iterative development. Nothing is final until the game ships. An iterative approach allows me to keep the thrill alive as I can constantly try new ideas and if some don't work it's not painful to just drop them.

One of the big draws for me in becoming an independent developer was that I wouldn't have to deal with tyrannical managers and potential interdepartmental politicking. I love working with other people, but sometimes you're forced to work with that person that seems to have no other purpose in life than to undermine everything you stand for. You've been there, right? Right?

Testing Doc Hahm's experiments at the testing grounds

I've found that working alone is extremely liberating but making important decisions can be agonizing. With endless possibilities how do I choose just one? In a traditional development environment there would be writers making decisions about story direction and other teams would just make it happen though each team would be vying for their concerns to be taken into account. The tech team would want to take out the epic fluid simulations, the art team would want to add more explosions and the marketing team would want to monetize and ruin everything. Wait, did I just say that? Yes. Yes I did.

Going ethereal allows you to go through physical objects

In doing it alone you have to take on the role of each of these teams. Every decision you make is not conflicted by an outside source but from within. As an independent developer you have to prepare yourself to experience severe self-conflict. Realize that this is healthy and normal. This isn't self-doubt and this isn't weakness. Just acknowledge that it can be hard and, at times, overwhelming. The trick is to never stop, don't sweat the small stuff and keep working until it's done.

PrintView Printer Friendly Version

EmailEmail Article to Friend