Defend Earth or Die! has launched! Oh yeah!

You can now experience what we've been working on for so long if you buy the game on the Xbox Live Marketplace. Want to try it before committing that $1 we're asking for? That's cool. We understand. It's your hard earned cash. So there's a trial mode that is available for every Xbox Live Indie Game. You won't be able to save your progress, but you will be able to play the first level or two and get a glimpse of what the game is like. That should convince you to part with a hundred pennies. And if not we'd love to know why.

We've already received lots of great feedback, and we're always interested in more. So if you play it feel free to drop us a line or a review. Who knows? You might influence an update or a port or a sequel. Are those things happening? Any of them? We'll let you know when we do.

We're obviously really proud and happy of this moment and glad that we can finally share it with the world. The best thing you can do is to also share it with everyone you know. Open up those social networks and link away.

It's been a long time. Too long. But we are back and there is some exciting news we'd love to share with you.

Despite the fact that we haven't been updating this blog regularly we have still been working on the game. There was a dark time we don't like to talk about from July 2011 through July 2012 when nothing got done. But other than that our planned tower-defense-in-space-on-the-Xbox game had been moving forward at a steady side-project clip for about three years after our last post.

Then the next gen consoles were announced this past May.

That really got us going, because we absolutely want this to come out on the Xbox 360 before the Xbox One launches in November. We know that a lot of players will be switching to the newest, shiniest console as soon as it comes out, so we want to make sure they have a chance to see and play our game before that happens.

So this summer saw a huge push of activity on all fronts. Deadlines were set. And adhered to, surprisingly. The list of tasks yet to complete is now small enough that I can count them using fingers on one hand. At one point there were several hundred. Challenges were conquered, pitfalls avoided, bugs squashed. We learned a ton about making games. It's been a great experience.

And now, finally, we're ready to share it with you. To give you a sneak peak of what the game will look like we've hand-crafted an announcement trailer which you can watch below.

And since we now have a name for the game, we can finally share that with you too.

Zen Otter is proud to announce Defend Earth or Die! coming to Xbox Live Indie Games soon.

The game I created in seven days is done! Battlefriends, as it's called, is launched. You can even play it right now. To get you excited, here's a screenshot of what a typical profile (mine) looks like early in the game:

Since it's finished already, here are some tips and tricks that I discovered along the way.

When to Use the Open Graph API

The new Graph API caters very much to the Facebook Connect crowd. So much so that the canonical way of getting users to authenticate is JavaScript based. If you have an app that exists somewhere outside of Facebook - a destination website like a blog that isn't dependent on Facebook - then the Graph API is great. However, if your app only exists within the canvas page on Facebook, then going with the old REST API offers you a lot more flexibility and power to interact with Facebook data. Easier authentication. Better tools with more options. But it'd be a really heavy solution in the former case. So use what makes sense for your specific app.

How to Use FBML

There is an option in the JavaScript SDK to have it render FBML on the page. It works, but just barely. The rendering time for any sort of intensive FBML (like the all popular request-form) is measured in minutes, and that's just not acceptable. Instead, using the force FBML hack is at least an order of magnitude faster.

Facebook Doesn't Like Transparent PNG's

You need both a 75x75 logo, and a 16x16 favicon to upload to Facebook. I discovered that if you try to use a PNG with alpha channel transparency, then Facebook automatically converts it to a GIF, which obviously has only binary transparency: a pixel is transparent or not. They control the threshold, and in every case it was set at something that made my images look horrible. I have no idea why they don't just keep the image the way it is. This conversion seems like more work on their part for a negative gain. In any case, do yourself a favor and convert it to a GIF yourself before uploading, so that you can control the threshold.

Regarding Playtesting

When making a game, actually playing it is really important. This may seem incredibly obvious, but going through the flows solo or with a robotic competitor is nothing like playing against a real live human being. You have to test the game with other people. They will do unexpected things in unexpected ways, and generally muck up your system. Doing this before exposing the game to a wider audience will probably catch most of the pain points other users might encounter.

Game Over

Now that this mini-project is playable, it's back to work on the tower defense game for the Xbox. This was a nice distraction for a while, but I think putting a time limit on it is a good thing. There's still so much to do for our first console game!

This post is part of a series about making a Facebook game from scratch in one week. Go read the Overview to find out more and see a list of all the posts.

Copy, Copy, and More Copy

There was little to no explanatory text on any of the pages when I started today. I added an intro, a help section, and a few lines here and there to give players some guidance.

I also had two big gaps: notes that said, "put terms of service here" and "put privacy policy here." I searched around online for examples and created my own version of each based on what I liked about ones I saw, and what seemed most necessary. I really would prefer to have the simplest and clearest text possible for these, but I also want to make sure that I'm as covered legally as I can be. The privacy policy turned out much nicer in that regard, as it's more of a "what we do with your information" whereas the terms of service is more "what you can and can't do with our site."

Styling

The second half of my day was spent styling the app. Almost all of the pages got huge overhauls, and I figured out a neat HTML/CSS trick to display a health bar that goes from colored to transparent and has text on top of it that shows up as light on the colored part and dark on the transparent. Most of the lines of code added today were in CSS, with a few in JavaScript.

Daily Wrap Up

That's it! The only thing that's left to do is get people playing it on Facebook and then submit it to the app gallery. I'll update the overview with a link to the game once it's ready.

Now for some stats about Day 7:

• Working Time: 7 hours
• Number of Commits: 7
• Total Number of Files: 65
• Total Lines of Code: 2436

This post is part of a series about making a Facebook game from scratch in one week. Go read the Overview to find out more and see a list of all the posts.

A Comedy of Errors

When I stopped working on Friday, the invitation code still wasn't doing what it should. The problem appeared to be the fact that when you supply a URL for those accepting the invite to go to, Facebook wipes the query string. Again, it is this totally unexpected, undocumented behavior that makes programming for Facebook such a pain. I wanted to try working on Saturday, but Google App Engine went down while I was trying to upload a new version. That made me give up until the next day I could work: today.

Also, a note that when you upload images to Facebook for logos (the 75x75 gallery image and the 16x16 favicon) transparent PNG's are not treated well. They go through some sort of transformation that makes them come out degraded and ugly. Better put a background behind them first, or switch to another format.

Finally: Something Playable

With the Facebook integration issues behind, there's actually a playable version of the game up. It's not pretty, but that's exactly what I'm going to fix tomorrow.

Daily Wrap Up

Now for some stats about Day 6:

• Working Time: 4 hours
• Number of Commits: 2
• Total Number of Files: 65
• Total Lines of Code: 1791

Update: Go on to Day 7.

This post is part of a series about making a Facebook game from scratch in one week. Go read the Overview to find out more and see a list of all the posts.

More Facebook Integration

The bulk of my day so far has been spent getting authentication working in a sustainable way, and then implementing some controls and features on top of that. Did you know that Facebook doesn't provide a way to tell if your access token is expired or not? Yeah, you're supposed to detect the error any time you make an API call and then re-authenticate. That could lead to a lot of repetition, so I wrote a wrapper to handle it, but seriously, shouldn't the SDK at least help with this sort of thing? The old API also had a quick method for getting the ID's of a user's friends who also had your app installed. Not so anymore.

It's having to deal with a couple dozen realizations like those that slowed me down yesterday. Progress has been better today, but it's really just an extension of what I didn't finish earlier.

I've switched the invite page over to pure FBML, and the speed increase is frightening - 5 seconds instead of 55. But here's something I was stuck on today for hours: Facebook only does POST requests to FBML pages, never GET. Why? I have no idea. Now if only they had some sort of error message that said as much... The final catch with FBML is that the domain the page is on becomes facebook.com, which means that any cookies you have - or sessions that rely on cookies - are no longer accessible. However, if all you need is something like the user's UID to look them up in your database (this is what I was passing around in my session) then Facebook has you covered by means of parameters sent to your page. Just check for "fb_sig_user" and you'll be back in business.

I also wrote some code to post to users' walls. I've never done anything like that before, and it feels like I have a lot of power with this ability. I'm trying to respect that and keep things to a minimum: one post per battle, and then any updates are comments to that post.

Next Steps

I was originally planning on just doing this within a "business week" of five days, but in order to give this project the treatment it deserves, I'm re-interpreting "week" as a seven days. I need the time because I still need to style just about everything, and create several logos for the game. It's work I'm looking forward too though.

Daily Wrap Up

Now for some stats about Day 5:

• Working Time: 7 hours
• Number of Commits: 6
• Total Number of Files: 62
• Total Lines of Code: 1663

Update: Go on to Day 6.

This post is part of a series about making a Facebook game from scratch in one week. Go read the Overview to find out more and see a list of all the posts.

Facebook Integration

I must say, the Facebook Graph API is a lot better than the old one. However, the official Python SDK is really bare-bones, and could use some nice convenience functions. Despite the fact that there is some good documentation about how to get your app authorized, the canonical way seems to be to use JavaScript. I wouldn't normally care, but the way the login system works, you have to get the user to click on a button in order to show a pop-up to them. I don't want that. I want the user to go to the address of my game and automatically be asked to approve it.

That's obviously still possible, but it took longer than I felt it should have. And there are a lot of little caveats that are buried deep in the docs, if at all. Things like the fact that your app is no longer authorized to do anything once a user signs out of Facebook. You have to ask for the special extended permission "offline_access" to do that, but I thought it would just be a part of authorizing an app. I'd wager most end-users have no idea what the difference is.

At the end of a solid 8 hour day I had my app getting authorized the first time, but there's still a lot of bugs around getting re-authorized for users that come back. I did find some good reading about the new process, and I'll use that to hopefully get things up and running tomorrow.

If you're not using FBML but want to use advanced features, then you're forced to use the Facebook JavaScript library to load up XFBML, and it is the slowest thing I've ever encountered online. It's probably my biggest complaint about this whole process. I got invites working (something the JavaScript SDK should support natively) and the request to Facebook to process the XFBML is regularly about 55 seconds. That's just not acceptable at all. Luckily, there's a way to force FBML for a single page, and that will probably speed things up. I'll try that out tomorrow.

Unforeseen Consequences

Throughout the course of integrating Facebook I've had to change the model a lot. Battles now have a join table for keeping track of users' stats, and I've added "elements" to users and powers, based on Facebook data. This should make the battle system a little more complex, and interesting. In order to keep things balanced with these changes I had to add another set of 3 powers. So we're up to 27 powers. That's 9 categories of 3. And 6 of those are elemental based now.

Daily Wrap Up

I didn't get nearly as much done today as I wanted to. Facebook integration is slow-going, and difficult to debug. It would really help if they had clear, concise examples on how to do exactly what I want, but that's probably a pipedream. I'd settle for a easy to use sandbox mode.

Now for some stats about Day 4:

• Working Time: 8 hours
• Number of Commits: 5
• Total Number of Files: 59
• Total Lines of Code: 1513

Update: Go on to Day 5.

This post is part of a series about making a Facebook game from scratch in one week. Go read the Overview to find out more and see a list of all the posts.

Monetizing

As I mentioned previously, I'm going to be trying out Social Gold for this experiment. Their interface and sign up process are pretty good, though there were a couple questions that seemed unnecessary - why do they need to know my title, for instance?

The Social Gold API is fairly standard, and easy to understand. Compared to TrialPay working with their system and interface is much, much better. My complaints are small, but I think valid. To start, there are some inconsistencies between the key names you send Social Gold, and the ones they send back: "ts" and "sig" versus "timestamp" and "signature", respectively. This just seems silly - why not make them exactly the same? They also mix GET and POST parameters in their callback, which means that if you're using a framework like Pylons - which can only retrieve parameters from one or the other - you're going to get stuck. And why do I have to send the name of the virtual good to them as a parameter in my request when they have it in their database? That's just redundant.

Their awesome sandbox mode more than makes up for these shortcomings though. It made testing and working out the kinks of my implementation a breeze.

Perhaps the best part is that there's no approval process. You just set up your goods or currency and it's ready to go. If there are problems they email you with exactly what went wrong. This made it very easy to get setup quickly, and troubleshoot when I ran into problems.

My single biggest complaint is that you can't re-name, delete, or re-use virtual currencies. This nullifies any use for their potentially huge time-saving feature where you can automatically "load a template" to fill out a form with the same info as a previously entered product. It also means that you have to get things right the first time around. It's strange that you can edit everything else after it's been saved, but not this.

And finally, while I'm at it, it'd be nice if their redirect URL had the offer ID automatically appended to it. I've had to add it by hand to each of my 16 virtual goods.

Daily Wrap Up

Now for some stats about Day 3:

• Working Time: 6 hours
• Number of Commits: 3
• Total Number of Files: 57
• Total Lines of Code: 1242

Update: Go on to Day 4.

This post is part of a series about making a Facebook game from scratch in one week. Go read the Overview to find out more and see a list of all the posts.

Planning

To start today off, I realized that I need to break the larger project into some smaller deadlines for each day if I'm going to pull this off. Here's what my tentative plan is:

• Today: Get the web app working.
• Tomorrow: Monetize.
• Thursday: Facebook integration.
• Friday: Bug fixing, polish, and launch.

An important note is that monetization needs to happen sooner rather than later, mostly because the third-parties that do it often have a human who's job it is to review virtual goods before they're approved in the system. This can take a few days.

The most aggressive of those days is definitely today. I need to code pretty much all the HTML, JavaScript, and Python. I'll save the bulk of CSS and design for the polish part of Friday, but I'll also be tweaking it as I go.

Sessions

When planning my external dependencies, I totally forgot about sessions. GAE doesn't have those built in, and I definitely need them. I've previously used gaeutilities, but it seemed a little heavy for this. So I'm trying out gae-sessions for the first time. The integration point feels a little wonky, but it's working, so I feel like I can't complain.

Progress

So getting things working without Facebook integration already being there is turning out to be pretty hard. I did what I could, but it's going to need a lot of love on Thursday to get things right.

What I did accomplish is coming up with a list of powers, refactoring the model a bit to be more generalized and eliminate those join tables, and adding some art. I got icons for all the types of powers (there are 24 total, with 12 different types). I just wanted to search for a free to use icon set that would have what I need, and luckily, I found one.

There's also a decent amount of work that's been done on fleshing things out in the battle system. I'm going to end up using a couple different browsers to test this, in order to emulate the multiple players going back and forth.

Daily Wrap Up

Now for some stats about Day 2:

• Working Time: 7.5 hours
• Number of Commits: 6
• Total Number of Files: 57
• Total Lines of Code: 1054

Update: Go on to Day 3.

This post is part of a series about making a Facebook game from scratch in one week. Go read the Overview to find out more and see a list of all the posts.

Facebook Setup

The first thing I wanted to do is create the actual Facebook application. It'll force me to pick a unique name, and I'll get my API keys. Even though I've made Facebook apps before, finding out where to install the developer app - which enables you to do everything - was a huge pain. I couldn't find it anywhere on the Facebook.com interface, and searching for things like "developer" gave me results like "Arrested Development." Very funny, Facebook. But I'm trying to get work done here. Ultimately, it was Google that pointed me in the right direction to the Facebook Developer Application. So I added that, and then clicked the "Set Up New Application" button.

That's when I hit my first big surprise: Facebook now requires accounts that want to develop apps to be verified by adding a mobile phone or credit card. Not a huge deal, but it is a recent change.

Then the moment came to pick a name for the application. "Friend Fight" was already taken. I wanted something unique, but also descriptive. I thought about "Buddy Brawl," which was available, but it sounded way too generic for some reason. After looking around at some other apps, I finally settled on "Battlefriends."

It's important to remember to go grab a canvas URL for the application as soon as possible. If you edit the application settings it's the first item on the "Canvas" tab. My first choice, "battlefriends" was taken (although going to the URL leads to a 404) but "battle_friends" was available, so I just claimed that.

Google App Engine Setup

As I'm using Google App Engine (GAE) for hosting, and they also require a unique name for apps - of the form yourappname.appspot.com - I figured it would be prudent to sign up and get the closest name I could to the Facebook one. Not surprisingly, "Battlefriends" was available.

Code Setup

I start most projects these days with a generic GAE scaffolding project. I generally follow MVC, and the starting folder structure resembles that:

• project root
• controllers
• templates
• static

All of the application configuration is in files in the root directory, including the model, which I usually keep in a single file for smaller projects.

Then, I initialized all of my external dependencies. As I use Git for my version control system, this entails setting up some Git Submodules. These include the Facebook Python SDK, Mako for templating, and Blueprint.css for styles. Beyond that, there are only two immediate changes to my typical setup, and they're both static files:

• xd_receiver.htm - the cross domain communication channel for Facebook to use
• fb.css - a stylesheet to mimic Facebook styles
• NOTE: even though Facebook says the width of the canvas page is 760px, I've found that due to scrollbars, the container element shouldn't be larger than 710px - with Blueprint as the CSS framework this leaves room for 18 of the 40px columns

Site Map

The next logical step after all that is to create a site map. Although not a requirement per se, Facebook likes it if apps have dedicated help, privacy policy, and terms of service pages. So those are some easy ones to include in a list. I'll also need at least a landing page, a user dashboard, and some pages for the actual game - inviting friends, challenging them, and the actual fights. Not to mention pages for buying moves and attacks. This will probably change, so I'm not going to spend too much time on getting it perfect. Just enough that it can guide me through getting a first version of the game up and running. Here it is so far (in roughly the order that the navigation will appear):

• index/landing
• profile/dashboard
• store (list of items)
• pages for purchasing individual items
• list of current fights
• pages for individual fights
• leaderboard/challenge friends already playing
• invite/challenge friends not playing already
• help
• privacy policy
• terms of service

The final piece of this is that I'll need an admin only section. At least initially this will serve as a place to reset fixture data as I develop. Later I'll put in reports, such as the average number of fights a player has going on, how players have moved up and down the rankings, and which items are purchased the most or least.

So, the first bit of new work I did was to flesh out all of the template and controller files to fit this site map. I then modified the routes to pull it all together. I also created some basic navigation so that I could quickly check that all the pages were hooked up correctly.

Concept Refinement

As you may have deduced from the site map, even as I work on this I'm getting more ideas about the details of the game mechanics. Specifically, I don't want players to be limited in the number of simultaneous fights they can have. And the items they can buy will be divided into three categories: powers/moves that will consume some meter or points which they can re-use as long as they have enough points, actions that can only be performed once per battle (the most powerful), and consumable items which get depleted from use and have a common stockpile - i.e. using the last consumable in the player's inventory in one battle removes it as an option from all battles instantaneously. The total number of fights a player has engaged in will also effect their strength and power (as a small multiplier), and which moves they have available - e.g. completing ten battles will unlock a more powerful version of the basic attack.

The Model

In order to really start doing work I need at least the beginning of a database schema to work with. The obvious objects that I need so far are these:

• Users - so I can keep track of each player's stats, powers, and battles.
• Powers - the moves/actions a user can take, with three subclasses (as discussed previously): point-based, once-per-battle, and consumable. Users can only have one of each of the point-based or once-per-battle powers, but can have many of each consumable. Note that this implies two join tables: one for keeping track of if the once-per-battle powers have been used within a specific battle (these entries can be deleted when the battle is over) and an inventory for maintaining a count of consumables on a per user basis.
• Battles - a record for keeping track of the current state and the ultimate outcome (though I won't be recording every move, as that makes more work for myself and would inflate the database very quickly). Users can have many battles. Battles have exactly two users.
• Orders - for internal tracking of purchases and revenue. Orders have exactly one user and one power.

I coded the model file with those preliminary objects, and that's where I'll end for the day.

Daily Wrap Up

There's still a lot to do, and the game isn't near playable yet, but there's a solid foundation both in code and conceptually. Tomorrow I'll lay out some test data and try to get the basic mechanics working.

Now for some stats about Day 1:

• Working Time: 7 hours
• Number of Commits: 5
• Total Number of Files: 40
• Total Lines of Code: 577

Update: Go on to Day 2.