I’ve been working on a few new games lately and the speed of Flash Builder’s global search has been getting worse and worse and worse. You can restrict the search to only .as files, but every now and then I mix in xml or json or even txt files and this seems like something that would only frustrate me in the future.

Today I finally noticed what was slowing it down: scanning the .git folder. It doesn’t actually find any matches in there except for what’s in your commit messages, but there are hundreds and hundreds of resources that it spends time scanning. There are two possible solutions to this:

1) When creating your flash builder project, do it one directory down from your git repo (i.e. if your .git folder is a level above your Flash Builder project, it’ll never see it).

2) Flash Builder (and Eclipse, I guess, by extension) allows you to mark folders as “derived”, which it will then exclude from the global search. The only hiccup is that Flash Builder doesn’t show you hidden folders in the Package Explorer. You can trick it, though–do a global search that will find something in one of your commit messages. Right click on the .git folder in the search results window and you can select properties (and mark .git as a derived folder).

Search is fast again! Woohoo.

I just got a fairly form-letterish rejection from the Amazon App Store:

When pointing to other apps or websites from within your app, including up-sells, ratings, version updates, or upgrades, our published policy calls for the completion of purchase to be from Amazon.

Steps to reproduce this issue as it appears in this app:

1. Install and launch the app.
2. A pop-up appears stating “This application requires Adobe AIR”.
3. Tap on “Install”.
4. It links to Google play.

To point to a specific app, the Download URL must be http://www.amazon.com/gp/mas/dl/android?p=[packagename] (where [package name] is your package name). The link will become active when the app is live in our store. If you want to link to the list of all your applications on Amazon use the URL http://www.amazon.com/gp/mas/dl/android?p=[packagename]&showAll=1.

Please correct the issue(s) we found with your app submission.

After Googling around for a half hour or so, I ended up finding a lot of forum posts complaining about this issue… but mostly dating from when the Amazon App Store was brand new and everyone was building their AIR apps on the command line. As this postmentions, there’s actually an ADT flag called “airDownloadURL” which specifies where the Install link will take users.

Seeing as I use Flash Builder and not the command line compiler, this is of no help whatsoever. I did manage to find a reference in my .actionscriptProperties to “airDownloadURL” — but had no idea if that would actually fix it in the final build. Re-submitting an app to see if a bug is fixed is a pretty slow update loop… but luckily I noticed this screen while exporting this time around:

Yep, doesn’t get more derpy than that. To be fair, almost all of the Flash Builder Chrome says “Google Android”, so the alternative download URL on the Play store doesn’t seem anomalous in the least until you get a rejection letter. I did read Amazon’s native extension documentation fairly closely–you’d think they might mention this in big bold letters somewhere if this is a common rejection reason.

I recently left Crowdstar just shy of my three year anniversary. Before the memory of those three years fades into the crunch of trying to make my own games, I thought I’d look back at the best and worst parts of those three years. Before I get into that, though, it might be worth a little bit of background.

After Piqqem (my first job out of school) folded in January of 2010, I resolved not to get another job and to dive full time into indie game development. I’d only been a half-time employee for the last year anyway, spending the rest of the time focusing other random pursuits (iphone and xbox indie versions of Filler, a review site for other indie games, a couple of new Flash games, a movie showtime search engine that got a nice write-up on TechCrunch but was too expensive to run). One month into “going indie,” a recruiter emailed me pitching three different companies: AuroraFeint, Sibblingz, and Crowdstar. The story was the same on all three–game related, YouWeb funded, growing like a weed, desperately in need of engineering bodies. Instead of getting back to the recruiter, I looked up Peter Relan (the founder of YouWeb) and shot him an email asking how you get into the program.

We chatted on the phone and he thought I should have a chat Suren and Jeff, the two founders of Crowdstar. What actually happened ended up being more of a 3-4 hour “interview” of sorts. I talked with a couple of their Flash guys for awhile about what they were working on and games I’d made–one of them later told me that it wasn’t a real interview, but a “push-on” (their attempt to recruit me). After chatting SQL and ruby awhile with the guys at Sibblingz, I finally went into a big glass office with Jeff and Suren. Jeff immediately asked for a resume (which I hadn’t brought) and ended up settling for a LinkedIn profile chock full of all the bullshit made up websites and companies I’d been tinkering on for the last year or two.

We talked a bit about my background, but the thing that stands out the most was one question Jeff asked me: “Would you rather make a game that a million people play and like or 100,000 people play and love?” Crowdstar was clearly already in the business of the former, but up until that point I hadn’t really considered it. Only one month into my “make games to support myself” experiment, I was still making games that I wanted to play (and not really considering games as an economic vehicle). I gave him the 100K answer, which is clearly what he wasn’t looking for. Then again, I hadn’t signed up for an interview–I thought I was coming up to Burlingame for a chat about social games in general.

Peter invited me over to his house a day or two later and offered me the job of lead dev on Happy Island. His pitch was simple–working alone or even starting a new game company would put me way behind where Crowdstar was already, and he was willing to make me “CEO” of a game and let me run it like my own startup. It was a tempting pitch, but at first I was mostly in it for the money–I told him I wanted half a percent. Playfish had recently sold to EA for $300 million dollars and social games were exploding, so I figured if Crowdstar could grow to that scale and exit within a year or two I could clear $500k-$1mm over the life of a 4-year vest. I’m not sure he heard me right, because he said yes and asked if I could start the next day. I said yes.

As it turns out, Happy Island was in flux. Originally developed by Sibblingz, it was a flash game with a Rails backend. My first day was a Wednesday. Sibblingz was due to roll off the game on Friday, and Crowdstar had not a single rails engineer. As you might guess, that first week or two was crazy as hell–setting a good tone for what would follow. A rough timeline:

• Happy Island (Feb 2010 to May 2010)
• It Girl (May 2010 to April 2011) — also, I got married!
• Cancelled FB Game (April 2011 to November 2011)
• Closet Wars (Nov 2011 to Oct 2012) — also, had my first kid!
• ??? (Nov 2012 to Feb 2013)

Rather than go through it all chronologically, I’m just going to ramble a bit about the ups and downs–mostly ups!

The Good: Working at Scale (and Scale Technology)

Before joining Crowdstar, I had experience with all the relevant technology–Ruby on Rails, MySQL, Memcached, Flash… but never at scale (well, maybe a little on the Flash side). The day I joined, Happy Island had 2.5 million DAU (still climbing on it’s way up to 3 million peak). The other web apps I’d worked on maybe peaked at around 100-200 DAU. When Filler launched and hit #1 on Digg back in 2008 (when Digg was cool!), it peaked at around 200k players per day. Not even 10% of what Happy Island was doing in normal day. On the web side, the biggest I’d done was a single cache server, a single app server, and a single MySQL box. Island was running multiple memcached boxes, a bunch of sharded, replicated MySQL instances, and a boatload of app servers (each running still more rails processes through Unicorn).

The first few months were crazy–coming up to speed on a new codebase (both client and server), writing sharded database code, adding new features, fixing bugs… and all the while monitoring the live deployment and waiting for things to go wrong. Operating a game at that scale basically requires you to think like web-dev MacGuyver. Something is always breaking or going down or getting hot, and hotfixes deployed in the heat of the moment are more like duct tape than carefully engineered responses. Crowdstar had (and still has) a great ops team, and I probably learned as much in my first two months at Crowdstar as any other time in my life.

Most of the hard work (architecting and scaling up) had already been done on Happy Island, though–I was mostly a caretaker. When I later rolled off and started up the It Girl team, we were building from scratch. I was lucky to work again with the guys at Sibblingz (now Spaceport), who are much better engineers than I am. For It Girl we ditched MySQL and Memcached entirely, instead building the entire backend on top of Redis (including an in-house ORM instead of ActiveRecord). Redis has since gone in a slightly different direction (everything in memory instead of just the keys), but for our purposes it was fantastic.

It Girl never got to the scale of Happy Island and we had a few quirks pop up with Redis, but all in all it was a mostly smooth ride from 0 to tens of millions of users. Not having to think about which shard your data is on, along with not having to worry about caching, simplified development tremendously (and is one of the reasons we switched to Membase for future games).

The Bad: Not Working at Scale

After It Girl, I jumped on to another Facebook project that eventually got cancelled. By that time the company had shifted to mobile, and that shift brought a lot of changes to how we architected our games. Because it’s harder to rely on an internet connection and harder to mess with the in-memory data of a cell phone, mobile games tend to be a lot more client-authoritative.  With simpler back-ends, there’s much less demand for server-side engineering.

Going from such a frenetic scale and pace (multiple deploys per day and constant monitoring) to something that felt almost pedestrian was a radical change. Part of this was due to the way mobile games operate. There’s no such thing as “push it and see what breaks”–mostly because of Apple’s onerous submission process (with 6-7 days being required for any client-side update). From what I know of console development, most mobile studios operate a lot more like our AAA cousins: develop -> QA -> release. It’s certainly a “healthier” way to run a business, but in many ways it felt like the taming of the Wild West.

At Crowdstar I was always the “rails guy” at a company mostly filled with PHP guys. The back-ends have now gotten simple enough that there’s not really a compelling argument for using Rails (actually, Closet Wars is a hybrid of Sinatra and Rails, but still) over PHP. Most of the back-end operations consist of either “get me this key” or “put this data in that key.” Had I stayed on, what was initially pitched as a Rails & Flash job would’ve been PHP & C++ going forward.

Addendum: Scale as a Shipped Game Title

I’ve noticed that my experience with scaling Facebook games has affected how I view other companies outside of Crowdstar. Being an engineer in Silicon Valley, I’m constantly bombarded by recruiters via email and LinkedIn. Before working on scale projects, I wouldn’t have thought twice about the size of a company and instead just looked at what they do. Now I’m a little reticent to even consider joining a company that doesn’t have a crapton of traffic–it’s less fun! (Not that my own projects will have significant traffic any time soon).

Likewise, it seems like there’s a perception of hiring people with scale experience that reminds me a lot of the AAA console industry. Most job reqs at companies like EA will explicitly state that one shipped title is required, but there’s no way to get that one shipped credit without getting hired by someone with no credits. It seems like a lot of companies are looking for people with scale experience and not willing to hire those without it. In that sense I’m incredibly lucky to have been baptized by fire at Crowdstar.

The Good: Doing it All

Once I had a handle on actually running Happy Island at scale, I got to start playing around with the product a little more. None of the Crowdstar games at that time had time travel cheats (i.e. skip ahead 8 hours), which made it difficult to do some gameplay testing. There were serious problems for high level users, so I took it on myself to rebalance the entire game’s economy. After building a “simulator” version of the game where I could play two-to-three sessions “per day” just by pressing a button restart the session, I played dozens and dozens of playthroughs and eventually created a pretty tight escalating economy. It wasn’t perfect, but I think it was pretty fun (and certainly extended the life of that game). Even though my title was “lead dev” at the time, I was in fact more like a producer–coming up with new features, balancing the economy, running the revenue reports… as well as a good bit of code.

When we later added the actual job title of producer (while I was on It Girl), I became the producer for It Girl (and the unshipped title and Closet Wars). Up until recently, though, titles didn’t mean a whole lot at Crowdstar. Being entrepreneurial (read: curious and willing to poke my nose into places I probably shouldn’t), I wore almost every hat possible: client-side engineer, server-side engineer, QA (before we had a “QA Department”), product manager, content manager, producer, game designer, data analyst.

Working at a startup with more tasks than bodies affords someone who likes to get their hands dirty (me!) tons of opportunities to move around and try new stuff. This was probably most true on It Girl–as we “grew up” as a studio and people took on more well defined roles a lot of that flexibility went out the window. Even on my last game, though–Closet Wars–I was putting a lot of time into being producer, doing game design, and engineering. One of the reasons I never really wanted to go into AAA games was the fear of being a cog in a great machine–the fact that I was still able to wear quite a few hats on team sizes approaching 20-25 people has done a little to allay that fear.

The Bad: The Hours (and Commute)

The downside to having more tasks than bodies is that there never seem to be enough hours in a day. This was especially bad when I first joined–we were still in hyper-growth mode and I was new to a lot of the tech. Because I had as much equity as I did (and, to be honest, because I wanted so badly for us to succeed), I always felt like I needed to be the last one out the door. For a long stretch on It Girl, I’d say I was putting in 80-90 hour weeks. I wasn’t the only one doing it, though–I remember many 2-and-3 a.m. nights with the Sibblingz guys. We had this sort of visceral feeling that the future of the company rested on our shoulders–I don’t know how true that is, but we definitely felt it like a force weighing down on us.

Those kinds of hours weren’t sustainable, obviously. After Crowdstar raised a ton of V.C. money and started shifting more into a “stable studio” mindset, the hours definitely calmed down into a more normal 10-to-7:30ish, 50-hour Silicon Valley work week. Even working 10-to-7:30 on most days, though, I had to tack on an extra half hour to each side for my commute. Factoring in 8 hours of sleep and a bit of time to make dinner, I essentially had 1 hour in the morning and 3 hours at night to fit in everything in my life outside of Crowdstar.

It took me most of that first year to “finish” ColorTangle, the game I’d been tinkering with when I started CrowdStar–a game that I’d estimated needing another month to finish. And it probably was about a month’s worth of work–just crammed into a few minutes here and there on the fringes of 8-10 months. With tinker time going out the window, I also cut back on almost all of my leisurely pursuits: exercise, moviegoing (and I’m a film major!), reading books, and playing other video games. I’m a firm believer that game development is a creative pursuit, and when your world narrows to the point that you’re not consuming any media and keeping up with your body, that creativity suffers.

Once the baby came (February 2012), that claustrophobic feeling of never having enough time doubled or tripled (and especially never having time for myself).  I’m sure that happens to all new parents, but I was on the verge of quitting for almost all of 2012 to try to win back some of that time. It certainly doesn’t help that I have an almost-neurotic desire to stay on top of all the current tech trends and try out every new gadget and technology that comes my way. What kept me going (besides my wife telling me not to quit) for most of that year was the fact that I had my own team (Closet Wars), we were making something that I legitimately thought was going to be great, and my team was awesome.

In that sense, I’m really excited to be working from home now–the hours and the commute were my #1 excuse not to exercise (except “i’m tired” or “i’ll start next week” or “slept funky last night”…), so hopefully I’ll be able to repurpose some of those hours into dropping 20 pounds this year (my pre-Crowdstar weight–damn you catered lunches!).

The Good: A/B Testing and Optimization

It’s one thing to read about A/B testing best practices on Hacker News, and quite another to run tests yourself on a massive scale and see what kind of impact they can have. When I joined Crowdstar, they were already A/B testing a little bit of stuff–but usually only running one test a time and modding on the user ID (which, at our scale, was probably random enough but not as statistically rigorous as it could’ve been).

While we were launching It Girl, it became pretty obvious that there were a lot of knobs and levers to tweak. The current mod-on-the-user-ID system would only let us run one or two tests simultaneously, and it was pretty brittle at times (was it user that end in 0-4 or 5-9 that were the control group?). I built a new system for It Girl that was not tied to user ID and was event-based, meaning we could split users into test groups at various steps in the user life-cycle. This was probably my favorite bit of code I wrote at Crowdstar, and now that I’m out I’d like to re-write it some day for my own personal use.

As an example–when we launched the boyfriends feature ,we knew we wanted users to have a minimum number of “clique members” (friends in the game) before they could access the feature… as well as a minimum level in the game. We were able to A/B test:

• the optimum level to introduce the boyfriend features (testing for # of people who get a boyfriend)
• the number of friends which should be required to get the first boyfriend (optimizing for k-factor… i.e. at 4 friends less people get a boyfriend, but is it more than ¼ of the people who were willing to invite one friend?)
• the number of friends required to get each boyfriend from BF #2 all the way through BF #10

Between those tests and dozens of other tests we ran on price points, progression speed, and monetization features, I’d say that the A/B test system doubled or tripled the LTV on It Girl and taught us all a tremendous amount about player behavior. Maybe this goes hand-in-hand with running a product at scale, but it was also a hell of a lot fun to have access to that much data (in near real-time) and that much flexibility to test things.

The Bad: Time Off

When I joined Crowdstar, we were given two weeks of PTO (I think it’s up to 17 days now, which is better but still not great), which is totally standard for a new company. I travel a lot, so I was always scraping the bottom of the barrel when it came to PTO… and on several occasions either went way negative or took long stretches of unpaid time off.

Because all of the games we made were games-as-a-service, the usual lulls in the game product cycle just don’t exist. There was always something important going on, so picking a time to skip out for a week or two was always tough. Compounding my lack of time off was the fact that my wife works at EA–where she gets 4 weeks of PTO, the entire week of Christmas, and usually a couple of weeks of under-the-table comp time whenever they finish a game.

I had a bunch of people at work say things like: “how do you have so much time off?” — and I would always answer the same way: “I don’t.” I’m lucky that financially I could take the unpaid time (and was in good enough standing with the company to get away with it), but I always thought it was a downer that the majority of people worked so hard and got so little time off to show for it (though most people probably don’t travel as much as my wife & I).

To be fair, though, one mitigating factor for the lack of PTO was the company trips. My first year we went to Italy, renting a villa in Umbria and hacking for a week while surrounded by gorgeous sunflower fields (with day trips to Venice, Rome, Siena). My second year we had a hack week in Maui, and we just recently came back from Puerto Vallarta. These trips were awesome, but ostensibly still “work trips.”

The Good: Running a Team / Teaching

When I joined the company, most people were either flash engineers or server-side engineers. There were certainly other full-stack devs on board (most of the dev leads, in fact), but there wasn’t really anything pushing people to do both. On my teams I tried to push everyone into learning ruby and actionscript (as applicable). Ruby is fun and weird and awesome, and actionscript is easy if you’ve ever done any other dot-syntax-based-language ever. Having a developer who can implement an entire feature end-to-end just saves so much more time and stress over having to have two people agree on a spec and implement in parallel (for small stuff anyway, obviously that doesn’t scale).

There were some exceptions–we had a few truly truly great flash guys where it actually was faster to keep them in Flash and let other people support them. Even those guys, though, probably got more exposure to ruby than they would’ve liked (anyone can use the console, right?). That sort of education and guidance (mostly on the ruby side, but even in Flash) was the most rewarding part of being a dev lead (or even a producer) to me.

Even being a dev lead itself is pretty fun. Once a team gels pretty well, you get a pretty good sense for what each team member is capable of (or capable of being pushed into). I found the whole thing to be kind of like a puzzle–given the following pieces, how could I best match the tasks to the people to play on all of their strengths and push them forward? Maybe it’s because my mom is a teacher, but there’s something really satisfying about developing other people around you.

Once we shifted to mobile, though, I switched more onto product/design/project management and less of a lead developer–not having the really really deep knowledge of C++ and mobile that I had on the Flash side, I never had the confidence to try and be a leader there. That freed me up in some ways to focus more on design and product, but it was also pretty frustrating at times.

The Bad: Running a Team / Not Doing it Yourself / Not Doing Anything

While teaching was fun, there were parts of being a dev lead and product lead that I wasn’t so well suited for. I think I’m probably a horrible micro-manager. I can fit the whole product in my head at once, but I’m not so good at writing all that stuff down into a useful document and delegating. Because there’s no central repository for how things should work, people have to keep asking me how it would work. Some people will just go for it (which is sometimes awesome and sometimes not, but generally preferable). I ended up having a finger in every pie, but not really feeling like I had full control over any of the pies (I mean–I knew what was going on in all of them, but didn’t have enough time to fully understand any one pie).

Because I keep the whole product in my head, I have a pretty good sense of how I want everything to work (both at an experience level and technically). Trusting someone else to do something “right”, where “right” means how I would have done it, is next to impossible. The trick, which I was getting better at but never fully mastered, is to just let your people figure it out and make mistakes as they go. Back in the It Girl days, Pete Hawley (now at Red Robot) told me that the crux of it was basically to hire really good people you could trust and then get the fuck out of their way. I think I could get there eventually, but for now I’m still too close to the development and the architecture side of things. It would grate on me at times when looking at code people had checked in because that’s now how I would’ve done it–but most of the time it would be a perfectly reasonable solution.

At other times on mobile, I felt like I had nothing to do at all. As a producer, though, that’s the state you should strive to be in–if you have nothing to do, that means you’ve got your whole team right where they should be doing what they need to do. As we got closer and closer to launching Closet Wars I was able to jump on bugs and help fix things.  Bug-fixing, which can feel like more of a junior task sometimes, is actually a great thing for a used-to-be-programmer-but-now-manager to help out with. Fixing bugs is much much easier than adding features, as it mostly involves tracing logic errors and correcting them instead of architecting whole systems. Because I might be called away at any time if a fire came up, it wouldn’t be fair to the devs for me to take on a big feature–more often than not they’d end up stuck waiting for me to finish it.

The Good: Talented Artists

I saved this one for last, because it’s probably the most important. My background is mostly in making heavily procedural, art-light games–mainly because I suck at art and work mostly alone. I remember having a conversation on a Flash forum before I joined with an artist who was looking to partner up with a developer and split everything 50/50–my theory at the time was basically that art was a commodity resource and I’d never give up more than 10 or 20% for an artist. I should find that dude and apologize.

The absolute coolest thing about working at Crowdstar was working with the amazing artists there. Our art director had incredibly high standards for artists. It could be frustrating at times when we needed a body in the door for UI or other art positions (I remember interviewing a couple that I was blown away by that he said “meh” to). In the end, though, it definitely shows in the games. It helps that the games we built were essentially content-delivery vehicles (lots of digital goods and weekly releases), but I don’t think I would’ve stayed nearly as long as I did without some of the artists we had.

For nearly three years straight, I’d constantly get blown away by the things they came up with. You’d think after creating 5,000 garments for It Girl there would be absolutely nothing left in the tanks creatively, but I think the artists both on It Girl and Closet Wars (now Top Stylist) got stronger and stronger as they went. The stuff those guys churned out on a regular basis was just fun to watch.

Coming from a place where I wanted to make games but didn’t know any artists, I always remember being frustrated at how I was going to get around it… art was a barrier that prevented me from making what I wanted to make. Now, I have a pretty large network of artist friends who are willing to give me recommendations to their artist friends (or take on contract work themselves). And having worked closely with really really good artists for several years in a row, I feel like I can communicate a lot better with artists when I do bring them on board. Just because of that, I feel like I’m no longer limited in the kinds of games I want to make (which I think is huge!).

The Bad: The Breakup

I debated whether to include this section or not–I’d say my three years at Crowdstar was more or less 33 months of good times and three months of sour grapes. I worked on Closet Wars from November of 2011 through around October of last year, when the decision was made that it wasn’t hitting it’s performance metrics fast enough.

Even before the axe fell, though, cracks were starting to form. There had been a round of layoffs in the summer (which mostly unphased me, because I was having so much fun on Closet Wars), which spooked a lot of our best people into finding new jobs. My team mostly held together through the worst times, but by September or so we’d lost our lead artist, our UI artist, and were about to lose one of our best engineers. Zynga’s stock was in the shitter, which was making the whole industry look bad. I considered leaving then, but Peter and Jeff talked me into staying through the end of the year and seeing Closet Wars through.

A couple of weeks after I agreed to stay on, the decision came down to scrap Closet Wars and repurpose it into Top Stylist. A new game designer was brought on, and I was asked if I was willing to produce the hatchet job (that’s probably too harsh–Top Stylist is a pretty well designed game, it’s just not my baby). I’d only taken two weeks off when my son was born, and in California you can take up to 8 weeks of paid family leave. I thought a better solution would be to take a month off, come back refreshed, and then figure out where I could be helpful.

When I got back in early November, everything seemed different. I’m not sure if it was the month off or not, but it was almost like they didn’t know what to do with me. I was given the vague assignment of researching new tech. Mostly, though, I was just ignored. Not being on a team and not being assigned anything meant that most days I just sat there and did nothing. That’s fun for like a day, but I had just had four weeks off and I was raring to get to work on something. Small things would come up–ruby questions, questions about how we’d built things or how the art pipeline worked–but certainly not a full day’s work. It almost felt like a game of chicken, waiting to see which would happen first: getting fired or quitting.

I was travelling for a lot of December and January, and upon returning let Jeff know I was ready to leave. He asked if I’d stay on and finish one last project, but in the end the pieces for that project didn’t quite come together quickly enough and we kind of synched up and decided to call it a day (or three years!). In the end it’s kind of a silly way to go out, but I was ready to do my own thing and Crowdstar is a much different company than the one I joined three years ago. No longer really a “growth” startup, they’re in full-on game studio mode. They have a clear direction they’re headed and need people to fit into pretty specific roles to get them there. If I’d stayed, I probably would’ve dropped back down to being just a “server dev” or a “client dev.”

The only thing I really regret is that I was never able to do anything with all those stock options (which will just expire in 90 days). I could exercise them, but locking up that much cash in a studio that’s raised a ton of VC, over which I no longer have any influence, and which has no guarantee of an exit seems pretty silly when I could just invest that cash in myself and my own projects. It’s a little crazy to think the thing that acted as such a good carrot during the long hours of the It Girl days will come to nothing, but that’s just part of the startup game.

The last few months were a little strange, but overall I think it was a great decision to jump on when I did. It’s easy to wonder what would’ve happened if I’d stayed the course on doing indie iphone games back in 2010. Comparing what I know now about game design, free-to-play, art, operating a game as a business, even technology–I still love some of those old designs I was working on, but they probably would’ve been disasters. I’m really excited to get a “second chance” at some of those designs, but revisiting them through the lens of my Crowdstar experience. It should be a fun ride!

I came a cross a link to Ukiyo-e Heroes last night (reddit? facebook?). I remember seeing it when it was first on Kickstarter and thinking it was kind of neat, but it’s come a long way since then. The art itself is pretty cool, but what struck me were Dave Bull’s videos on the woodblock print-making process. Their collaboration essentially works like this:

1. an artist designs the print
2. the woodblock artist slices the design into 10-20 layers, then painstakingly carves each piece by hand over a couple of weeks.
3. each piece individually bears very little resemblance to the design as a whole, but when fitted together in layers they create the final design
4. once the “development” is done, an unlimited number of prints may be created from the blocks (this is still a manual process, but one that can be outsourced)

Is that really so different than a small video game? Replace the woodblock artist with a programmer and the artist with a game designer (which, sometimes, is still an artist). Once a design is in place, the programmer carves it up into various classes and units of code and painstakingly brings it to life. After some weeks or months of toil, a finished product emerges which is capable of spawning many copies. There may be a little bit of manual work left for distribution, but the game at that point is ostensibly an artifact much like various woodblocks.

Game development is certainly a lot more iterative than woodblock carving, but it’s always nice to draw inspiration from random places.

Several people have sent me emails and messages now that Hundreds is out, ranging from “reminds me of Filler” to “dude, they cloned your game” to “it even looks like Filler.” I’ve been casually following its development, so I finally downloaded it over the weekend and gave it a play.

My thoughts generally fall along two lines–an analysis of the game as a game and its similarities to Filler, and my thoughts on the game as indie theater (is that a thing?).

In general, though, I like Hundreds. Quite a bit. It’s pretty, it’s hard, and I clearly like the mechanics.

Similarity to Filler (Inflation Mechanic?)

To be honest, Filler is barely a game. I read an article on a new physics engine for Flash back in the fall of 2007 (APE – Actionscript Physics Engine), downloaded it, and started playing with it. I wanted to see how the circle particles interacted with each other and how many it could handle, so I made a little thing that let me mouse down to start growing a circle particle and release to drop it.

Something in that toy sparked a memory of Jezzball from years ago, and within an hour I had Filler more or less running in its final form. I refined it a little over the next couple of months (instead of growing the radius linearly, the balls “inflate” proportionally to their area/”volume” instead–they grow quickly at first and then slow down), but the shipped version was basically that prototype with some menus and ads.

Hundreds uses that same mechanic–inflating a ball–but to different purpose. Where Filler was an arcade game with a neverending level progression, Hundreds is a puzzle game with specific, authored puzzles. This works really well for the inflation mechanic, as it solves the one major problem I never really solved with Filler–lots of particles leads to lots of collisions which leads to slowdown. By introducing a finite number of particles in each level, the lag issue goes away entirely.

Hundreds also introduces many new types of particles where Filler had only the inflation-balls and the bouncing pop-balls. Most of the particles are pretty neat (I like the hockey pucks that you can slide around, but don’t much care for the chained-together-balls). For me so far (about 60 puzzles in), the puzzles generally fall into two categories: acrobatics and patience. In the acrobatic levels, there’s usually some sort of dexterous action required–batting a razor particle through a small opening, moving the pucks around to block razor particles, using two-finger controls to make quick arrangements. In the patience levels, it’s usually a matter of slow scanning, waiting for an opening and deftly inflating just a little. The former feel like totally new puzzles to me, but no matter the particle complexity the patience levels end up feeling just like Filler to me.

Which is fine.

I like Filler, and I like that same feeling in Hundreds. I certainly don’t own the inflation mechanic or even the combination of patience and inflation. I like the mechanic, so I actually wouldn’t mind seeing more games that use it. Over the years I’ve sketched/prototyped out a few such games that I’ve never gotten around to making:

• a Filler-style tower defense game where you drop particles onto creeps, who crawl over the rubble at the bottom (prototyped–it’s pretty neat)
• a bubble golf game — imagine a pinball layout (wedges/ramps) with several “air” catches that you’re trying to fill up. kind of like inverse pachinko, but you can control how big your ball is (sketched)
• a bubble platformer — a little mario guy who runs around collecting bubbles on the sea floor who can “inflate” as a shield against danger… but also collecting too many bubbles makes you jump too high (sketched)

There’s probably a lot more!

In terms of art style, Filler doesn’t really have one. 0×555555 isn’t an art style, it’s just a color of gray that I like. The original Filler is minimalist in style because I wrote in entirely in code and didn’t own Photoshop or Flash at the time (which I used profits from Filler to buy). Filler 2 isn’t really any different than Filler (other than the challenges) — it’s more of a “here’s what it would have looked like if I’d had the resources the first time around.” I think Hundreds is a bit obtuse in places (I thought the game was broken on the first frozen particle), but in generally I really dig the colors and design aesthetic.

Hundreds as Indie Theater  ($2.99???)

So now that I’ve established that I like Hundreds… I don’t think it’s worth $2.99. “Worth” is a really strange word, though–something is worth whatever someone is willing to pay for it, and clearly people are willing to pay $2.99 for Hundreds.

But they’re not really paying $2.99 for the game Hundreds. They’re paying for a ticket to the indie theater.

Adam Saltsman (Canabalt, Old Spice Saves the World) and Greg Wohlwend (Solipskier, Gasketball) are fairly well known in the indie game scene, and they’ve done a great job stirring up attention before the release of Hundreds. Buying the game achieves two goals–it gets you the game Hundreds and it acts as a vote of support for its creators to keep doing what they’re doing. In that sense, this is another form of Kickstarter. We want there to be successful indie developers so that we have something to strive for, and supporting games like Hundreds lets us tag along for that ride and keep our own dreams alive. In that sense, it’s absolutely worth paying $2.99 for.

But tweets like this are probably a disservice to aspiring game developers:

This exact same game by an unknown at $2.99 would be a disaster. Probably even at $0.99. By building a large social and media following and hyping its release well ahead of the launch day, they’ve managed to do something that most indies can’t–widespread press coverage, Apple featuring, and enough initial downloads to launch into the Top 10.

The message that’s being sold in the media is simple: “build a high quality original game and you can command a higher price point and be successful.” But I think Hundreds is more of a marketing success than a truly innovative and original game (not that it can’t be all three–I just think if you’re going to hold it up on a pedestal the most interesting piece is the marketing, by far). Certainly, the game could’ve been a dud and wasted all the hype leading up to its launch. A more accurate story might be “build a large internet following and you can successfully sell content to them (see Louis C.K.).” Game developers should always strive to build good games, but the takeaway from Hundreds should be how to launch a successful game and not necessarily how to design/develop a successful game.

I’m curious to see what will happen when the price ratchets up to $4.99 on the January 10th. I think it may be able to hold its chart position on tablets, but will probably drop like a stone on smaller devices. Which is actually kind of a shame, because I do think it’s a good game.

I’m a huge fan of the iPhone and iOS for a lot of reasons, but I just picked up a Lumia 920 for my next 2-year AT&T contract. As a developer, I have no intentions of abandoning iOS–it still has the best ecosystem by far, and it’s a lot of fun to tinker with (once you get everything set up). I’ve published three apps for iOS, one for WebOS, and none for any other platform. Part of my desire to switch comes from wantering to tinker with something new, but that’s not enough reason to abandon the most robust mobile ecosystem.

When thinking about smartphone usage, I break things into a couple of categories: how often do I do something and how important is it that it be awesome?

Critical Tasks:

• phone calls and texting: maybe 5% of my phone usage
• driving directions: maybe 10% of my usage

• finding restaurants / phone numbers for ordering takeout: 5% of my usage
• listening to music while driving: 20% of my usage
• reading email: 10% of usage
• showing people pictures of my kid: 5% usage

• reading twitter (and occasionally FB) feeds: 10% usage
• looking up random things on IMDB/Wikipedia: 5% usage
• playing games / using other misc. apps: 30%

How has the iPhone treated me over the last 4+ years at each of these tasks? Pretty well. In both phones that I’ve owned, though, there has been a steady degradation of performance for anything web-related over the two-plus-year lifespan of the phone. Apple, bless their hearts, does not give two shits about backwards compatibility (backwards performance, maybe? is that a thing?). They are in the business of selling phones, and it is in their best interests to keep you on the upgrade treadmill. I fucking love gadgets, so I’m actually fine with this. But I need the phone to last at least two years. For both my iPhone 3G and my iPhone 4, I feel like I got about a year and a half of amazing phone and six months of pissed-off frustration. My wife was able to grit through the slowness of her 3G (we got our original phones at the same time) and get a 4S, so I’ve actually been able to compare my iPhone 4 against her 4S.

I can’t count how many times in the last few months I’ve searched for something in the browser only to get a timeout. Or been unable to calculate directions. Or unable to perform a search on google maps (I held out from upgrading to iOS 6 in the hopes that performance wouldn’t degrade even further, never mind the maps “upgrade”). My first instinct would be to just blame AT&T for shitty cell service (even though I usually have full bars). But this go-round the blame was squarely on Apple–for the past month or two whenever I get “stuck” on my iPhone 4, I’ve been grabbing my wife’s 4S and performing the same task (with, theoretically, the same cell coverage). No problems.

To be fair, I’ve never had any problems with the phone as a phone–but from my shortlist above you can see that the two things I care most about in a smartphone are reliable maps and the ability to use the phone. For the whole two year lifespan of a phone. Even in the medium and casual-importance tasks, though, I’ve been getting frustrated. The iPhone mail client is a disaster and hasn’t been updated (as far as I can tell) since my original iPhone 3G. It takes me forever to get into a photo album on Facebook (not strictly Apple’s fault, but the internet degradation plays into the slowness), which I’m doing more and more now that I have a kid. Twitter and FB time out all the time (internet). The only place I haven’t gotten frustrated is with Spotify (which is great) and with the wealth of apps available. If you subtract all those great 3rd-party apps, though, I’m mostly left with a bunch of 5-year old, half-baked, un-delete-able apps that all get thrown into a folder called “Default Shit.” Except that you can only put 12 apps in a folder, so Newsstand gets its own page behind everything else.

With this in mind, I decided a few months back to switch to a Lumia 920. I haven’t had it long enough to form a full opinion of the hardware/software, but here are my initial thoughts:

Apps: Facebook, Twitter, Kindle, Netflix, OneNote, Chase (bank) — all seem about the same as the iOS counterparts except the FB app, which kind of sucks. I love that it pushes photos to the lock screen, though.

Missing Apps:

• Pleco (a Chinese flashcard/dictionary/OCR translator that I paid $50 for on iOS… well worth it!) — I also have this on my Kindle Fire, so I’m still using it.
• Mint — I’m a compulsive balance checker. I hope this is coming.
• 8Tracks, Spotify — Nokia Music seems pretty inferior so far, but I’ll give it a few more weeks. I downgraded my Spotify back to the $5 plan until they get a WP8 client (they have one for 7.5, which is weird)
•  Nike+ Fuelband — can still synch at my computer, but it’s not as cool
• Scramble With Friends — (WP8 has Words w/Friends & Draw Something, but no Scramble) I’m liking Wordament better so far. Most of my friends beat the shit out of me in Scramble, but the nervous “need something to do and i like spelling” compulsion is nicely served by Wordament
• Tiny Wings/Bejeweled Blitz/Robot Unicorn Attack — these are my “keep coming back to” games, which I’m giving up
• Starmap — another pricey iOS purchase ($10? it’s been awhile). there are a couple for sale on WP8, but none seem as feature complete
• Ecobee — my thermostat has an iOS app to let you set the temperature without leaving the couch. it’s neat, but i never used it that much

Camera: supposedly a lot better, but I haven’t noticed a big difference in still yet. the videos seem much better (i’m not the most steady)

Notifications: silence! Obviously I haven’t bloated my lumia with as many apps as I had on my iPhone, but so far I’m enjoying the lack of notification barrage.

Pinning Contacts: when I say using my phone as a phone is important, I mostly mean calling/texting with my wife, which is probably 95% of how I use my phone as a phone. The ability to pin “her” to the home screen is awesome.

Email: still getting used to it, but so far it seems a lot better than the iPhone mail client. I also like how easy it was to synch my google calendar. Each synched mail account also gets its own tile, so no more wondering if it’s a work or personal email from the notification jewel.

Maps: so far I’m not in love with Nokia’s maps (despite the overwhelmingly positive reviews). i haven’t used them a ton yet, so the jury’s still out. the search seems much worse than the search in Google Maps for places of interest, but luckily the Yelp app works fine for that. i haven’t used the turn-by-turn yet.

Ringtones: for what’s supposedly one of the “customizable” phones, I’ve had a hard time getting my ring-tones onto the phone from my iMac. I’ll dust off a Windows machine and give it another go, but that’s been a sore point so far.

So now, one day in, I’m cautiously optimistic. The only major step backwards has been the lack of Spotify (for how I use it, at least). If I decide that I can’t do it, I can always return the phone (within the next 30 days) or hock it on eBay and buy an iPhone 5. As for keeping up with iOS ( critical for both work and as a gamer ), I’m not sure yet. My old iPhone 4 works fine on wi-fi, and I’m rarely away from my desk. If I can ever let go of my grandfathered unlimited plan with AT&T, the new mobile share plans all allow tethering. Most likely I’ll pick up one of the new iPod touches or the iPad mini. I still like iOS. A lot. I just don’t think I can rely on an iPhone for two years for my critical-use cases.

I’ve been reflecting on my Ludum Dare experience for a couple of weeks now.

I’d heard of Ludum Dare, mostly through friends on Twitter posting updates about it. I’d also done hackathons and game competitions before, so I kind of went in to it assuming it would work more or less like those that I’d already done. It doesn’t. Ludum Dare is definitely its own thing. The first thing that struck me when signing up for it was that the whole thing runs on WordPress. Once you create an account, you land on the admin page showing ~30,000 posts. As a developer, my first thought was just: “what the hell?” How can that possibly work? I poked around the admin for a bit, then went back to the home page. Sure enough, there’s just an unending stream of posts coming through, and anyone can sign up and just start posting. Again–how can it possibly work? How do spammers not just fill it with porn and penis enhancers? How does anyone find anything? Maybe it works because the community is small enough right now, but how could it possibly scale? All those questions ultimately don’t matter–for now it does work, and it works pretty well.

Clicking on a username (like mine: http://www.ludumdare.com/compo/author/simianlogic/) takes you to a stream of their activity. Likewise, clicking on a tag can get you to the stream for a particular competition (i.e. http://www.ludumdare.com/compo/category/ld-24/). The vast majority of games on the site are barely working prototypes, abandoned after competitions end. Skill levels vary wildly, most of the art is terrible… yet it works. The whole thing is just filled to the brim with optimism–which is to say, lacking the pessimism that seems to pervade most indie game hangouts. For those that are making a real go at games as a living, the idea of sharing an idea is almost toxic. What if someone steals my idea? What if they think the game sucks and won’t buy it later? All that paranoia is mostly unfounded. Making a game is fucking hard, and it’s a near-miracle that anyone ever finishes a game of any size. But still… don’t ask me what I’m working on currently. That cynic attitude is entirely missing from the Ludum Dare community.

You can click on the link above to see what I worked on in LD48, but the TLDR; version is that I only had ~12 hours to work on it, but got a Flash prototype up and running with no “real” sound, graphics, or levels implemented… I didn’t even make it to “evolution” parts of the prototype. At competition end, I was expecting a selection committee would play through the 1000-odd entries (really? 1000 games in 48 hours?) and winners would be announced within the week. Instead, there was an announcement that the games were now in “judgement” and that everyone should try to play and rate at least 25 games.

*eyes roll*

First thought: there it is–the community works because of forced participation. My only other experience with such a system is the XBox Live Indie Game channel, which is forced participation in the absolute worst way. The only way for a game to go live is to have at least three other people peer review your game: download it, flash it to the XBox, and then spend a couple of hours trying to make it crash. Peer review is miserable, and the only reason people do it is because they have to in the hopes of a quid-pro-quo review from someone else. Because of the forced participation, you end up with a forum full of people who don’t really want to be there but feel compelled to try and be “visible” so other people can see that they have a game in review.

It was a huge surprise, then, that LD’s “forced” participation doesn’t suck. For one thing, everyone has just made a game in the same 48-or-72-hour block of time, which means there are now ~1000-1400 people looking for feedback instead of the handful of XBox Live Indie developers who are ready for peer review at any given time. “Reviewing” a game really just means playing it for half an hour or so and rating it on a couple of metrics like fun and sound quality. Because you’re playing to play and not trying to see if it crashes when you unplug a memory card while saving, the experience isn’t that tedious.

Participation also quickly becomes a positive feedback loop. I played a few games after the competition ended out of curiosity, just to see how far other people made it (well, really, how behind I was compared to other entries). Every time I’d rate a few games, I’d notice that my game would pop back to the front page of the reviews. Interesting. There are actually algorithms working behind the scenes of the entry listings to try to guarantee quid pro quo reviews. If you review a lot of games, your game will be much more visible and therefore receive a lot more reviews.

At that point reviews and comments on your own game become sort of a drug. I’d refresh the page every couple of hours to see if I had any new comments–much like launching a game on Kongregate or Newgrounds but without, you know, the effort of actually finishing a game. No reviews for a few hours? Shit, then, just go play a few more games and wait. How’d I do? Not great in competition terms (#442 out of 1000), but I scored well in the two categories that matter for a prototype: innovation (#31) and fun (#239). The whole thing was a pretty fun experience, though!

Other random takeaways:

• Because I’m lazy, I was only playing web-based games (unity, javascript, flash)–it would have made my life a lot easier if there was a filter for only web games, but I can see how that might break the tit-for-tat review process.
• I was amazed at how many of the entries had sound. For me, sound is always the very last thing added to a game. That tells me that either (a) I’m putting way too little emphasis on sound or (b) if I want to “do well” i should pay more attention to the scoring categories.
• It would be cool if each entry had to submit an estimate for how many hours they got to work on the game. It’d be interested to see a graph of hours-spent vs final ranking.

RubyMotion released a new build today which supports GDB debugging. I did my early Flash games with just a text editor, the command-line compiler, and FDB, so the concept of a command-line debugger isn’t totally foreign. Still, I’ve gotten pretty used to nice GUI debugging tools. Those are hopefully on the way for RubyMotion, but in the meantime I wanted to see if there was anything I could do. The debugger in RubyMotion supports a simple debugger_cmds file with breakpoint commands, so the first thing I looked for was a way to set breakpoints in TextMate (even keeping them in a file somewhere). At worst, I figured I could put some comments (“#BP:blahblahblah”) and do something similar to the TODO viewer. Cumbersome, annoying to disable… not the best idea.

While looking around, I stumbled across the SublimeGDB package for Sublime Text 2, along with a couple of RubyMotion bundles for making builds easier (a syntax bundle and a build helper called SublimeRubyMotionBuilder). That was enough to give it a shot. I’m pretty new to Sublime, Python, and GDB–so I had no luck trying to get RubyMotion to connect with it out of the box. I imagine RubyMotion is doing some alchemy under the hood, but I was willing to settle for visual breakpoints.

The SublimeGDB has a “view breakpoints” action, but this doesn’t map exactly to a file. There’s probably a cleaner way to access the data directly, but here’s what I settled on:

Within RubyMotionBuilder.py (in SublimeRubyMotionBuilder), I duplicated the “RubyMotionRun” action into “RubyMotionDebug” (along with creating a corresponding rubymotion_debug.sh and adding entries to the command/menu/keymap). That function already finds the Rakefile for the RubyMotion project, then calls out to a shell script. Here’s my RubyMotionDebug function:

class RubyMotionDebug(sublime_plugin.WindowCommand):
	def run(self, options=""):
		view = self.window.active_view()
		if not view:
			return
		
		dir_name = FindRubyMotionRakefile(os.path.split(view.file_name())[0])
 
		if dir_name:
			#COPIES BREAKPOINTS (REQUIRES GDB... PROBABLY A CLEANER WAY TO DO THIS)
			window = self.window
			window.run_command("gdb_open_breakpoint_view")
			bp_view = window.views()[-1]
			window.focus_view(window.views()[-1])
			time.sleep(0.1)
			bp_view.run_command("select_all")
			bp_view.run_command("copy")
			window.run_command("close")
 
			file_name = os.path.join(dir_name, "debugger_cmds")
			f = open(file_name, 'w')
 
			rm_break = re.sub(r'-1 - \/.*/app/', 'break ', sublime.get_clipboard())
			f.write(rm_break)
			f.close()
			
			#go back to the window we were in
			window.focus_view(view)
			#END BREAKPOINT COPY
 
			sh_name = os.path.join(this_dir, "rubymotion_debug.sh")
			file_regex = "^(...*?):([0-9]*):([0-9]*)"
			# build console is not required for Run
			#self.window.run_command("hide_panel", {"panel": "output.exec"})
			settings = sublime.load_settings("Preferences.sublime-settings")
			show_panel_on_build = settings.get("show_panel_on_build", True)
			if show_panel_on_build:
				# temporary setting to keep console visibility
				settings.set("show_panel_on_build", False)
			self.window.run_command("exec", {"cmd": ["sh", sh_name, dir_name, options], "working_dir": dir_name, "file_regex": file_regex})
			# setting recovery
			settings.set("show_panel_on_build", show_panel_on_build)

The sleep is a little dirty, but I kept ending up with an empty paste buffer because of the time needed to render the BreakpointView. There’s probably some way in Python to check if gdb_open_breakpoint_view has been defined (i.e. the SublimeGDB package is installed), but I’m pretty content with it for personal use. I’ll probably map the Toggle Breakpoint command to something a little easier (currently you have to right click and select the menu item), but it’s a pretty compelling reason to use SublimeText for doing RubyMotion development (also the autocomplete seems a lot better).

RubyMotion + Break Points

Update: I put all my tweaks in a fork over at github (https://github.com/SimianLogic/SublimeRubyMotionBuilder). Just add a package repository in sublime, delete the old SublimeRubyMotionBuilder, and install the one from my fork. I don’t want to submit it as an actual Sublime Package because (1) I don’t know how (and am lazy), (2) there’s still a dependency on SublimeGDB which means it can’t stand on its own as a package, and (3) I’m sure the guys at RubyMotion are working on better tools anyway. This is a temp hack at best!

I’ve been neglecting my blog even more than usual since joining CrowdStar last February (working on Happy Island and It Girl), but honestly I haven’t had a ton to report for personal projects. Until yesterday, when I finally released Color Tangle as a standalone flash game on Kongregate and Newgrounds, aFacebook app, a standalone website with Facebook Connect, and an iphone app.

I’d played single-color knot games before, but never had any interest in building one. I was actually working on a prototype for an explosive based game using APE (the same physics engine in Filler) when I had the idea to use APE’s grouping system to create collision rules–particles that collide with some but not all of the other “stuff” on the screen. I whipped up a quick prototype, and instantly recalled other knot games I’d played. It seemed like a perfect fit! I had the “first” level up and running in less than a day. I’d been looking for a simple project (and this is a very simple game) to try a multi-platform (facebook, web, iphone) launch, and this seemed like a perfect candidate.

The next task was building an editor–which took about a week. WIth editor complete and a dozen puzzles or so in hand, I next built out the website from scratch (Ruby on Rails hosted on Heroku). I got to play with Sass and Compass (which are awesome), got to play with the Facebook API (not so awesome), and experimented with the blueprint CSS framework (also awesome). I built a widget using LocalConnection so players on external sites could connect to the game via FB connect (which I thought was pretty damn slick). I even started on the iPhone app using OpenFrameworks, getting it to the point where I could play my handful of levels.

It was right about that point that a recruiter pitched me on joining CrowdStar, and the project just… died. In my year and a half plus at CS, I’ve learned more about web programming and games than any other time in my life, and I really haven’t had a lot of time to tinker.

I could’ve just released it–the flash app was working, the website was working, and the facebook app all worked. But I learned from Filler how important it was to be first to market on mobile, so I just let the project sit for a few months while I threw myself into my work on Happy Island. I jumped off of Happy Island and started working on It Girl in June. Between that and getting married last October, I had no free time at all for tinkering. My schedule finally started cooling off around February/March of this year, so I picked the iPhone version up and “finished” it. The only problem was puzzles. Creating a couple puzzles on most nights, it took me roughly 2 months to get up to the 50 puzzles I thought I needed for launch. I submitted the app to Apple in June and it was approved the first time around. I set a release date of August 25 (my birthday) to give me a couple of months to polish up the webiste.

Having not touched the website code for over a year, the FB API was horribly out of date. I got distracted by another project along the way (look for another iPhone app soon), but my self-imposed deadline of August 25 finally gave me the pressure I needed to get my ass in gear. After a couple of weekends to get everything migrated over from FBML to pure iframe Canvas, I invited a few friends to start testing it last weekend and launched it fully yesterday.

I don’t think it will do all that well on FB (I know just a little more about designing for FB now that I’ve been doing it for a year and half), but I wanted to carry the original project vision through to completion. In the end, it was a really fun technical project, and I really enjoy playing it.