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.