Each week, I think to myself "this'll be the week I announce my new company." And each time, there are a few (crucial) things yet to nail down before I flip on the "Open" sign in the window. Forget about polishing the game design. That's a problem I wished I could be solving right now. No, I'm talking about business administrivia. You know, the stuff you never had to worry about before becoming a sole proprietor.
The list seems to grow as fast as I can check things off: finding a host, finding a payment provider, defining product delivery and pricing...things that seem simple, but bog down progress at every step. Part of it is that I feel the need to research each before making a call. I want to bring at least a minimal amount of expertise to each decision, which means research. Which means time invested. Which means another week goes by and I'm still not prepared to receive traffic.
The Pre-Flight Checklist
So what are these things? What makes them so important that I can't launch without them in place? I'll do my best to get them down in a list here. Perhaps they'll be useful to others self-publishing their first game. And at the very least, it'll help me to itemize them in one place.
- Business Development - As covered in a previous post, setting up a business is its own project. There are quite a few considerations to be made in doing so, and I don't think one could do it in any less than a week. And even then, there are some additional items I forgot to cover, such as:
- deciding on a bank account for expenses/revenue
- deciding on a filing and accounting system
- implementing the above decisions
- Website - Your website will probably be your storefront if self-publishing, so this should receive significant attention. Depending on your aptitude with web technologies, this probably means at least another week of planning, development time, and testing. Probably double that. Considerations include:
- What info will your website present? The game, of course. But what else? Is there any background info on your game? What about company info? Will it have a newsfeed, or just pre-planned pages?
- What social media tools will the website have? Will users be able to follow your accounts from your site? Will you have upvote/like/retweet functionality? How can users contact you? Email? Phone? Post? Twitter? Facebook? Google+? Will you have company pages on any of those social sites?
- Where will users go to discuss your games and company? Assuming your game grows an audience, where are they going to go when they have questions or comments, or just want to share stories? Are you going to host your own forum, or rely on other community sites out there (or fans)? How will your forum work? What sections will it have? Who can post, read, upload, flag as abuse? Who is going to moderate your forum?
- Is your website going to have user accounts? How many types? What does an account grant to the user? How will you handle logins? Lost passwords?
- Is your webhost/server up to the task? How much traffic are you anticipating? How much does your webhost allow? What if you go over the limit? Does your server have any processing or memory limits, and how might that affect traffic limits?
- How are you going to handle website security? SQL injections, DDoS attacks, rainbow and brute force login attempts, etc.
- Are you going to backup the site anywhere? Where? How frequently?
- How will you handle developing on your site when it is live? Will there be more than one instance of the site, for development purposes? What is your migration strategy to make dev changes go live?
- Payment Provider - How will you receive payments from your customers? If you want to sell your game, customers have to get money to you somehow. You are almost certainly going to need a payment provider. Pixel Prospector has an awesome list. In fact, they have many awesome lists for indies on their site.
- PayPal - There are many providers, but this one comes up a lot. And it has some considerations that make it worth mentioning. PayPal is not a full-service payment processor, unlike FastSpring and BMT Micro. With PayPal, you are on the hook for figuring out local sales taxes for all your customers, and paying them to local governments. You are also on the hook for any product fulfillment actions (hosting the game files, sending links). Furthermore, PayPal has had made rather dubious decisions regarding frozen accounts and destroyed violins. They're a cheap service, to be sure, but make sure you know what you're getting into. The extra money per transaction may be worth it to avoid the hassle.
- Whomever you choose, you'll want to accept PayPal as a payment type. In fact, aim for many types of accepted payments. There is such a thing as too many types here, but consider who your customers are. Many may be too young for credit cards, so PayPal and mobile payments may be their only (non-gift) purchase option. Fortunately, most processors accept PayPal as readily as credit cards.
- What is your payment flow? Will you have a shopping cart, or just an order info page? How does the customer receive their game when finished?
- How will you protect against hacking? Most payment processors have a mechanism for guarding against spoofed orders, but be sure you understand and are comfortable with the tools before using them.
- How will you handle lost orders? Customers who lost their copy of the game (or login info)?
- Pricing Structure - What are you selling, and how much does it cost? Are you selling an executable file? Access to a website? Virtual items in a free game? Much of this should've been answered long ago during the game design phase. But, as I discovered, these answers can still change very late in the project. Sometimes as a result of internal changes, other times as a result of market changes. Still, you'll need to consider this topic at least once.
- What is the cost of goods sold? (a.k.a. "cogs") This is more than your development costs. It must also consider hosting costs. Your payment processor is another cost. And what about marketing? In digital goods, this may vary as the number of sold goods changes. But at least make sure you're not losing money on each sale (e.g. a flat "per transaction" fee of $0.75 means you shouldn't sell for under $0.75. Maybe not even under $1.00.
- Will you have a fixed price for your product? A variable price? Choose your own price? What is your price range? Ideally, this is informed by your business plan's target market. Do you sell 1000 copies at $20, or 4000 copies at $6?
- Will you have sales or other promotions?
- Are you giving away bonus items?
- Will you sell non-game items, such as t-shirts, soundtracks, or posters?
- Public Relations - How are you going to get the word out about your game? This, like pricing above, depends a lot on your game design. Your business plan should've explored this as well. It'll depend a lot on your product, and the people it's intended for. It'll help with the following considerations:
- What channels will you use to talk about your game? Magazines? Websites? Which ones?
- Are you planning on having a presence on Twitter? Google+? Facebook?
- How will you handle demo copies of your games, for reviewers at magazines or websites?
- Where does your target audience hang out? Where do they get their info on games?
- How do you plan to talk to your fans? Are you going to write a press release and blitz spam it to every news outlet? Are you going to tweet about what you had for breakfast before starting your day? Do you cross-promote with other game developers? Will you blog about fan-knit mittens when they send them to you? They sound like silly questions, but I think it's worth at least imagining how you'd handle such situations. What kind of voice will you have with your audience?
- Piracy and DRM - It's a dreaded topic, but you should at least give it a good amount of consideration. We're assuming here that as a self-publisher, you're charging for something. So what happens when someone gets the "something" without paying the charge? There are as many ways to approach piracy as there are developers, so there's a lot of freedom here. And truthfully, I think most methods (including no DRM) result in enough success to warrant people using them. So it becomes a matter of choosing the method that suits your style and product.
- How can your game be pirated? Can the file be copied and distributed? Can user accounts be shared on the web? Can other portals include it in an iframe? Whether you choose to have DRM or not, it's worth examining how the game could be obtained by those you didn't give it to.
- Do you care if it's pirated by players? Some people invest in DRM to deny players access until money is provided. Others view any player as platform growth and a potential source of PR, and are happy to have their game played by as many people as possible. I'm probably closer to the latter than the former. I'd rather 5% of 1000000 players paying for the game than 100% of 50.
- Do you care if it's pirated by businesses? What if a someone sells copies of your game without giving you a cut? Or what if they host your game on their site without your permission? This is what I do care about. It'd bug me if someone took my work without asking, and started selling it on his terms. Or worse, rebranded it as his own and sold it. By definition, that's money out of my pocket. And if a stranger approaches you and starts fishing around in your pocket, you do the sensible thing: you gut punch 'em. Putting one boot on his chest and shouting "Victory!" is optional.
Ok, I think this is where I'll wind-down my latest list-based post. I really seem to rely on bullet lists a lot. Must be my short stint as a producer still wearing off.
The above list is pretty substantial, but I'm sure I've forgotten something. That was kinda the inspiration for this post, after all. Things like the above just keep popping up, and I wouldn't go forward without first thinking seriously about each of the above.
I may never have it all covered, but at least I'll have enough covered that the stuff I missed is manageable.
I think.
