Saturday, May 20, 2006

How to create your own game company

How To: Create your own game company,

Posted May 19th 2006 8:00AM by Victor Agreda, Jr.
Filed under: Business, Design, Developer, Finance, Games, Internet, Utilities, Features, Windows, Macintosh, Linux, Windows Mobile, Symbian, Palm, Productivity, Web services, Shareware
how to create your own game company part twoIn part one I talked about a lot of the production tools: 3d apps, game engines, and so on. This time I want to tie that in to the business end. How do you run the company, and how do you make money?

First of all, I discovered PopCap Games offers their engine to developers for free. The license agreement spells out the details, but primarily all you need to do is acknowledge using the PopCap Games Framework. The practical upshot of using PopCap's engine? They might publish it. The practical upshot of getting an engine and look by a successful publisher? You can make money. You still have to file taxes, and do all the other business stuff you'd normally have to, but you get to skip the part where you worry about marketing, payment, etc.

One other development is the rather old Torque Exporter Plugin for Blender is now up to version .91. Since Torque is $100 puny bucks for an indie license, and Blender is free, that also seems like a reasonable choice for budget game developers. If you're still thinking 2D (or very limited 3D, like an isometric game), another option is the Arcade Engine for Runtime Revolution.

So lesson #1 in business: keep your costs low. I don't want to get into a lot of business advice, but if you want some great tips on what NOT to do, check out Ten Easy Ways to Screw Up Your Game Company, and Part 2 of the same. If you're really looking to make a company, and can get investors, there's a lot of funny and valuable lessons to be learned in those few pages...

And not to be redundant (which I'm good at), but Lesson #2? Pick the right product. I know, the author of Ten Easy Ways says the same thing, but this lesson is too important to miss. You can spend thousands on the Unreal engine if you like, but trying to make another Halo? Good luck. It's not impossible, but unlikely. Shoot for realistic early goals and clean up with original, playable content. Now, on to the software!
Building your team

So you've got an engine, you've got an idea, now what? Unless you're some kind of modern-day Da Vinci, you're going to need people to help out. I'm no HR expert, but I can safely say this might be the worst, most challenging, yet potentially most rewarding part of the process. For one thing, a great staff member can elevate the team to new heights. A bad worker can literally bring a project to its knees.

hiring peopleWhat to do? Be very honest with candidates. And force them to be candid with you. One of the coolest approaches I've seen to hiring involves a test in the form of a game from Procter and Gamble. You can start asking friends if they know anyone with the skills you need, and move outward that way. If you're lucky enough to live in a place with a major university nearby (as I do), another opportunity is offered in the form of student workers. And lastly, there's always online recruiting. Online is tough, even with the breadth of choices. It's just very difficult to gauge someone from a distance (kinda like it's hard to convey sarcasm in an email). The first place I usually look or post is Craigslist, and there's probably one in your area. If you're really desperate, there's always a professional solution like Elance.com. Mine those forums and consider targeted markets like GamesIndustry.biz and GameDev.net for talent with experience.

Personally, I've always been a fan of testing personnel. And since you're looking for people with a passion for games, why not host a LAN party, put them all on the block, and have a quick deathmatch? This won't necessarily tell you how well someone can allocate memory or manage UV texturing, but it'll tell you who the griefers are. Don't hire the griefers!

At the end of the day you need to at least have leads in the major development areas: Programming (or tech lead), Art, and Design. Programmers need to be drilled on their skills pertaining to your particular platform. If you need a Python programmer for Blender, don't quiz them on ActionScript. Artists should have a portfolio, and the ability to whip up some artwork on the spot. As for design, I'm referring to the game design. Chances are the game designer, or "vision keeper" is you. I'd still recommend bringing in someone with game design education or experience, even if they are only an advisor. Make sure to check this person's credentials though. Playing Kingdom Hearts for a week without sleep doesn't make you a game design expert.

Documentation

Game documents, who needs 'em? Everyone. Every TV show has what's called a Show Bible. This is the law and lay of the land. Is the main character a pedophile? That little detail might never be revealed on the show, but the actors and directors need to know it, as it would influence the characters and stories on the show.

The same applies to games, only more so. You'll need a Game Design Document first. The Design Document is essentially the vision, point, and basic rules, setup, and look of your game. It is truly the "bible" for your game. Extending out, you'll need an Art Bible, with examples of the look and feel of the game, the design of characters, basically any art in the game. And you'll want a Technical Design Document. This spells out things like your target platform, tools to use, and the potential problems with programming your game. If you're making a Flash game, how are your programmers going to simulate 3 dimensions?

The reason for these documents? Whenever there's an argument over what to do, consult the bibles. An Art Bible ensures a unified look for all the art assets, and makes your game look more professional. The Tech docs make sure the programmers know what to expect. And the vision absolutely must be spelled out. Listing everything you need for a game is an exhaustive process, but one you're going to have to do if you expect to ever finish the thing.

Project management and communications

Project management, in the simplest sense, is very simple. Take the end result desired (make a playable game), and start breaking this down into actual tasks, then plan those tasks across a realistic timeline. Check every day, week, month at different levels (big picture vs. details) to make sure those "milestones" are getting done as appropriate. Looking for an alternative to Microsoft Project? Personally I use a meatspace tool called a legal pad, but those of you wanting software should check out Open Workbench.

communicationsAs for communication with the team, the usual stuff works wonders. Instant messaging with Meebo allows you to be protocol-agnostic. Jotspot offers a pretty good wiki service. And Google's Calendar and Notebook might be just what you need to push dates and talking points. Although I personally think Basecamp is the bees knees. And then there's that old standby: email. I think Gmail has a pretty good advantage here too, due to Calendar and chat integration, plus a powerful search ability.

Each department is going to have specific needs however. Artists need a place to store and log graphics. Programmers need a CVS for managing code. Let's look at each department to see what they need.

Design: I consider design the actual game design, not art assets. Consider an all-purpose CMS like Drupal (which I'm a big fan of), or Typo3, which is actually used by some Blender nerds. What you're wanting to do is have a central repository for "the vision" of the game. A CMS is a good place to put those design documents.

Programming: these guys need a CVS! Essentially this is a way to check in or out code, without messing other stuff up. Managing code is a tough process, and I'm a hack myself. Besides, coders tend to be religious about ways to do this, so to avoid a holy war, I'll just point you to a great book on the subject-Open Source Development with CVS by Karl Fogel and Moshe Bar. Almost everything else is dependent on your platform of choice. Flash, as an example, has its own IDE for ActionScript inside the app.

Art: ultimately these are the guys with a need for a good filing system. This could be as simple as a file server, set up with a very strict nested folder system. For example, a folder with "Characters" could include subfolders of "NPC's," "Heroes," "Bosses," and so on. Inside those would be the model folders, texture folders, and perhaps backup folders for previous versions. You can also use CMS's like Drupal to set this up, as the nature of the CMS versatile enough to handle art assets.

Finally, there's another good ebook to check out: Producing Open Source Software, also by Karl Fogel. Karl's book is a wonderful introduction to the problems (and rewards) of working with a large group of squirrels, each one with their own agenda. If you're looking for more workflow ideas, check out this post.

Testing and marketing: mutually exclusive?

The QA portion of game development is generally a time when the time grows very large. Bug testing can be really expensive, but I don't think there's a need for all that. At least, not when you're the underdog! Years ago I read the book Guerilla Marketing, and it's had a profound influence on my view of marketing. This might be sacrilege, but I suggest you release the game as a limited public beta, and somehow reward bug finders. That's not a new idea (Google I'm looking in your direction), but might take some of the bug hunt pressure off your programming team. The key is to be very open about the stage your game is at. If it's really, really rough, maybe only test with some friends. Once you can more or less successfully navigate every level, that's a good time to open it to the world. If you're really wanting to spend the cash on QA, and I'm not denouncing that approach, Game Instict offers QA-for-hire services.

The bottom line is QA must be done. There are no shortcuts. During the development of Jak X: Combat Racing, the Naughty Dog team tested the online play every Friday night. They'd go home, dial in to a private server, and play against each other. Not only did this uncover code issues, it allowed them to collaboratively discuss gameplay issues. If you're really passionate, this won't even seem like work.

Making your money

So you chose a reasonable target platform that doesn't cost too much to develop for, you have a great team, and you've managed to test the game until the play is just perfect. The next step is to sell your game.

making moneyYou can find a myriad of advice columns on how to approach a video game publisher to sell your game. Some publishers come from a development background (like PopCap and now Gamelab) and might appreciate you more. Maybe not. The advantage of a publisher is that you get an expert in sales and marketing. That's the theory. As any musician will point out, whether or not that expertise is used is another matter... But the big point is to have a complete, playable game, free from licensing issues (like music). It helps to have an idea of how to sell your game too, especially if it is very unique. Publishers tend to be a little conservative...

So I say strike out on your own. Between guerilla marketing and online payment systems, I don't see why you couldn't at least generate a little cash yourself. This might even be enough to woo a tough publisher. So how do you sell online? I mean, aside from PayPal.

Unfortunately, Regshare.com isn't around any more (they're selling the domain, ugh), as they used to do comparisons of online payment systems. But probably the most recognized name in the business is Kagi. If you've ever bought a 3rd part Palm app, you might recognize them. MacDevCenter has a comparison of Kagi vs. DigiBuy and eSellerate, for those still looking to shop around.

You could also implement your own payment system, but that is as varied as the mechanism and platform you're developing on. My own company just uses Paymentech for processing credit cards, but I've found that's overkill for an indie shop. If you're just moving bits around, Kagi works well. If you're selling physical units, consider just setting up shop on ebay (or wherever you like) and go nuts.

Other resources

I am a regular reader of Gamasutra, and you should be too. Sloperama's advice pages are chock full of great industry info, on everything from game programming to the actual gameplay design. You might want to read and check out the blogroll on Greg's blog on Games, Design, Art, and Culture. If you have some time and want to have a little fun, check out GameGame, a card game about designing and pitching games.

If anyone has any other great sites (I know I've left out a ton), please post 'em in the comments. There's no easy solution to making your own game company, let alone a truly saleable game. But hopefully with enough understanding of the process you'll be a little closer to realizing the Next Big Thing on your own.
read more | digg story

No comments: