Children of Liberty in the IndieDB 2011 Indie of the Year Awards

Hi everybody! Quick update today to let you all know that my game, Children of Liberty, is currently in IndieDB's 2011 Indie of the Year Awards competition. You'd be doing me and my team a huge favor by just going to this link and clicking on Vote For This Game. We've been busting our asses on it all year and, interestingly, every time we post an update to IndieDB, it gets into the Top 50 games for a couple days, so it's definitely popular.

Need proof? Here are some stats. Bitches love stats.

Total Alpha Plays Since Alpha Launch on September 5: 904

Total Site Views Since Alpha Launch: 1,107

Total Views on IndieDB To Date: 4,235

Total Views on Youtube Channel: 4,408

Not bad for a game that's only been in free alpha for a couple months, eh? Over nine hundred plays! By casting your vote for Children of Liberty, you would be helping us:

• Increase our total playcount, bug reports, and hopefully sales.
• Garner further recognition among the ModDB/IndieDB/Desura Community
• Get our name out to media outlets like Kotaku, Joystiq, Rock Paper Shotgun, and whoever else is actually going to be paying attention to the contest.
• Offer incentive for inclusion in indie bundles such as Indie Royale and The Humble Indie Bundle (if a Linux release ever happens).
• Become a recognizable name for attendees at conventions such as PAX East 2012.
• Make us look really good for when we are ready to approach publishers.

If you haven't tried the game out yet, you can play it for free right now. I completely understand if you'd rather play it first before deciding whether or not to click the Vote button. But remember that if you DO vote, I will love you long time.

Preparing for The Global Game Jam

The Global Game Jam is a wonderful thing. It is an event where game developers the world over come together over the course of a weekend and jam out games based on a challenge. Last year's challenge was "Extinction," which led to some very wacky projects, some very serious projects, and stuff in between. Next year, it takes place between January 27 and 29 (make sure to register), but as is tradition we do not yet know the challenge.

Even so, now that we are only 2 months away from the GGJ, now is a good time to start getting ready. While I admit I have only participated in 2/3 Global Game Jam's (I missed 2010's due to flu), here are my Top 10 Tips that I think will be handy to anyone thinking of participating, veteran or not (because people LOVE Top 10 lists).

Weeeee!

1. Don't Shoot for the Stars

You are not here to make Skyrim. You're not even here to make Desktop Dungeons. You're here to make the first floor of The Binding of Isaac at best. All game jams are for making prototypes. Do not set out with the goal of making a final product. If you like your project and your team, nothing is stopping you from continuing development afterward, or even setting up a Kickstarter to help fund it. The Global Game Jam makes no claims on copyright or IP ownership of your projects as they stand at the end of the jam. This is awesome, and if you love your team and your project, KEEP GOING WITH IT! Just don't try to make it giant in the course of a weekend. Shoot for 3-5 minutes of playtime, enough for you to grab some footage in FRAPS to make a trailer.

Time's a-wastin'!

2. The One Hour Rule
The biggest trap any team can fall into at any Game Jam is to spend more than an hour coming up with what game to make. Keep in mind, you have 48 hours to make a game, and your space may not be open for more than 8-10 hours a day. This means you will most likely not be working on the game for the entire weekend (unless your team's like "Let's all go to Steve's place and keep working!") and you must use your time as efficiently as possible. The best way to do this is to get right to work and iterate your project as you go along, adapt it to what you are and are not able to achieve. Therefore, I like to spend no more than the first hour after the keynote coming up with the game's concept. Last year I worked out my friend Sam's apartment (which coincidentally at the time we referred to as our company's "Office") and so we were able to concept our game over a couple beers, laughter, our own white board, and general goofiness (the result of which can be played here). By the end of the jam we had actually made a complete game. Yes it is short, but it works, and that is a lot more than can be said about a lot of projects. Which brings me to my next point:

3. Be Prepared to Fail

Two days is a really short amount of time to make a game, and you can't always predict what will happen. Maybe your concept was too big for you to achieve, maybe nobody on your team actually showed up after the first day, or maybe, just maybe, your final product sucks. It's okay, they can't all be Gnilley. Failure is a part of life, and it is something you have to accept as a part of any Game Jam. When you do fail (and you will) take note of why you failed and use that as a lesson for your future as a game developer.

Remember this thing? Remember how they said this was what was making America fat? Yeah, that's a lie. We were all skinny when we were following it. Just sayin'.

4. Eat

Caffeine on an empty stomach is useless. If your project has a producer, make sure to send them out to get food for the team. DO NOT make them pay for it themselves. When you have no funding, you go Dutch. Make sure there is a good mix of food with enough real nutrients to keep your team going. Calories and sugar are nice and all, but what you really want is Vitamins, Protein, and good Carbohydrates; in other words REAL FOOD! My first Global Game Jam, we subsisted on nothing but Krispy Kreme donuts. We all felt sick, our productivity declined, we got into fights... it was a nightmare. At last year's Global Game Jam, we ordered Chinese. Our productivity was 10x better because we were able to think straight. Some other food choices I would highly recommend for game jamming are pizza (obviously), hoagies (or submarine sandwiches, depending on your colloquialisms), salads, burgers, cereal... whatever keeps you going.

Two Homers in one blog post? Why not!

5. Sleep

You may be tempted to pull all-nighters for the entire weekend. However, if you schedule your project's development properly, you won't have to. A good night's sleep, even if it's 5 hours instead of 8, will do wonders for your productivity. Before you know it, your game will not only be done but it will look sharp too. You may even have time for polish! So get some sleep every night of the jam, in a BED, not at your desk.

6. Bathe

For the love of Jehova, you're going 48 hours working in close quarters with up to 20 other people. They WILL be able to smell you. Do them a favor and don't stink.

Please be more up to date than this.

7. Bring Your Own Laptop
The space at which you will be working for the GGJ working will probably be a school and yes they probably will have some server space reserved for you. This does not mean, however, that they will have all the software you are accustomed to using. For instance, I recently started using Silo3D as my main 3D modeling toolset, and to be fair it is not as mainstream as Max, Maya, or even Blender. If you are a programmer accustomed to an engine other than Flash or Unreal 2.x (3+ if you're lucky) then there is no guarantee the school at which you are working will have what you know (though luckily the tendency for schools to have Unity installed has greatly increased since I was in college). Save yourself the risk and the downtime by bringing your own equipment. You should be able to request access to your host-site's GGJ server space.

As they say, knowing is half the battle.

8. Work With What You Know
The Global Game Jam is a learning experience, but it is not the time for you to claim you are a programmer and then start learning C++. At the start of the Jam, you will have a chance to tell everyone at your location what your skills are. Be honest, and find a team that needs your unique skillset. If you are an artist, tell everyone whether you work in 2D, 3D, characters, props, environments, etc. If you are a programmer, tell everyone what languages you know and with what engines you are familiar. If you work in sound, tell everyone if you focus on music or effects, if you brought your own equipment (including instruments), and what audio programs you use.

Great work, team!

9. Make Games People Can Play
(This one's going to be controversial, mainly because there are way too many different programming languages, but what I want you to take away from this is keep what you do as simple as possible for the user.) I have seen many, many projects fall into this trap. Even though we live in the era of pluginless, all-inclusive HTML5, many developers at Game Jams get it through their skulls that it would be a good idea to require users to install alien frameworks to have their games run. This goes for pretty much anything beyond Flash, Unity Web Player (its inclusion with Google Chrome makes it an exception), DirectX, Java, and possibly a few others. Making users install things like iPhone or Android emulators because you couldn't build the whole app, various PDK's, or Kinect Hacks is probably a bad idea. Even Silverlight falls under this "avoid" category. Do not scare away your players by requiring them to download all sorts of frameworks just to have your game run. You will be competing with thousands of other games, and if you intimidate a user from playing yours immediately, they'll move onto the next one.

Too cute to resist!

10. Have Fun!
Games are fun and making games is fun. Do not waste time arguing with your team. If no one can come to an agreement on a feature, either try both or try neither. In the end you will have a stronger game if you work in a team that cooperates. Keep yourselves fed, get some sleep, take a shower, don't frustrate yourself or your playerbase, don't argue, be ready to fail, hope to succeed, bring your own equipment, and be honest with yourself and your teammates. In the end, you will have a much more positive experience for remaining positive during the weekend.

If you haven't registered for the Global Game Jam yet, you can do so here. If your local site is booked up, send someone from it an email to see if they can squeeze you in or if you can at least have access to the keynote, challenge info, and any upload info you may need so you can host your game at the end. You can also be generous and open your own jamming site for people to work, but contact the GGJ organizers to find out how you can do this (I don't think the requirements are steep, you certainly don't owe them money for doing so, but there are a few guidelines).

Can't wait to see what you all come up with! See you in January.

Communication is Key

Ever have one of those days, or one of those weeks in my case, where one hand obviously is not talking to the other? Not to sound like Andy Rooney, but I have. It's become so frustrating to the point that I am going to make a blog post about talking. That's right: talking.

Let's start by talking about bundles. There have been a lot of those lately, from The Humble Indie Bundle to IndieRoyale to the latest Indie Game Music Bundle. As was mentioned on the blog Dino Farm Games, these are great for the developers who actually get in, but not so great for those left out. To be fair, it's not like every indie game ever can be in a bundle. After a certain point, there would be too many games included in a bundle for the price to be economically viable per developer, or it would be too expensive for most people to pay in the first place ($100 for 100 games seems awesome, but how many of those are you actually going to have time play?). For the sake of argument, however, let's say a new bundle pops up, and you are an indie developer with a game you'd like to be included, so you send those who run the bundle an email with a link to your game on the day the bundle goes live. A week goes by, you hear nothing back. You send them another, still nothing. Finally, on the third email, you hear that they are not accepting any more games for the next bundle. Sounds like a pretty frustrating scenario, huh? Sadly, it is a real one, and a tough one to avoid if you are just starting out.

Keep crying, no one loves you.

For all this talk about how great social media is, the one thing we've stopped doing is talking to each other. Situations like this could be avoided if people just had the guts to speak up and send out rejection notices immediately instead of dragging people along for weeks on-end. Unfortunately, lack of communication can really eat into a developer's schedule, no matter how small the team may be, and this goes for both outside-in (in the case of bundles or publisher deals) and strictly internally. In fact, internal communication breakdowns are probably the easiest to occur but also the easiest to avoid. For instance, if you have two programmers on team - say one handles input and the other handles AI - and neither programmer is letting the other know what's going on, certain features may end up neglected at build-time, and neither programmer would be happy about that.

And then before you know it, you're out of a job.

The first instinct is to go to the Project Lead or the Producer with new features to go in, and on big teams this make sense. If a problem arises, you want your Producer to know so she can find a way to solve it. As Extra Credits pointed out, though, your Producer will probably pull you into another Programmer's office and say, "Hey, can you solve this problem?" You can save 10 minutes (at least) in your work day by going to that Programmer's office yourself and asking the same thing. Plus, you save your Producer the headache of having to help you do your job. As an employee anywhere, it is part of your job to make sure you know how to talk to everyone there, not just your boss. To be completely blunt, nobody likes it when you go over their heads to solve a problem with which they are involved. People much prefer you'd come to them personally, and I think Producers/Leads would prefer their staff talk to each other instead of having to fill in every tiny hole themselves. Save your company time and money and let your peers know you have a problem. Then you can tell your producer at the daily meeting that you solved a problem on your own. That'll make everyone feel good.

A happy Producer is like a warm summer's day: forgiving!

On a small team, going to the Project Lead to solve a problem instead of the team member whose responsibility it is to solve said problem is practically inexcusable. Something is bound to get lost in translation in the short game of telephone between the three team members, and since your team may not be working out of one central location, it's not exactly easy to drag someone into someone else's office. If you have everyone's contact info, contact your teammates directly. Project Leads on indie teams wear many, many hats and really don't have the time to call someone for you when you have their number.

That's a lot of hats for someone who's not selling hats.

Which brings me to my final point. If you are on a small team, have a phone you can always answer, and if for some reason you can't, always return your phone calls. There is nothing more frustrating than leaving an important message on someone's voicemail only to have them not get it or not return it. Blackberries are notoriously bad at not letting their users know they have a voicemail. Android, iOS, webOS, and even flip-phones do a better job. When you are working, keep your phone next to you, not in your pocket, so that if you get a call you can see the phone light up instead of wondering if it is vibrating (and if you are in an office environment, please do set it to vibrate for the sake of your co-workers). People (well, extroverts at least) much prefer face-to-face or even voice-to-voice communication over six-word (or worse, six-page) emails. Emails are okay, though, especially if what you need to tell the person on the other end is highly technical (fix this code on like 346 to read blahblahblah, for instance). Text messages are too impersonal, and they often cost the receiver money for information you could have called them about or put into an email.

You paid a lot of money for this shit. I don't care if the call quality sucks: USE IT!

Lots of things to keep in mind, I know, so here's the TL;DR version:
1. Groups who run bundles get flooded with a lot of emails from a lot of devs. If they happen to get to you and select your game to go into a bundle, consider yourself lucky.
2. Talk to your peers first, not your leads/producers, when you have a problem they could easily solve.
3. Answer your gorram phone.
4. Emails are good for highly technical problems.

All in all, just don't be afraid to talk to the people you work with. It's hardly even going an extra mile, it's going an step. That's as far as you can go before you go any further.