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:
- an artist designs the print
- the woodblock artist slices the design into 10-20 layers, then painstakingly carves each piece by hand over a couple of weeks.
- each piece individually bears very little resemblance to the design as a whole, but when fitted together in layers they create the final design
- 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?
- 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.
- 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.
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:
- 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:
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).
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.
I’ve seen a few of these movie promotion ads on Facebook now, and I’m pretty much astounded at how big of a waste of money they are. The problem with an ad like this is the fact that there are only two ways I can interact with it: I can either become a fan of “From Paris with Love” or I can blacklist the ad for any number of reasons. I don’t want to blacklist it, because I actually prefer seeing movie ads about 100x more than seeing ads for “Scholarships for Dads” or “Christian Singles” or GroupOn…
The problem is–they’re not even asking the right question. Am I going to go see it in theaters? Sure. I loved Taken, and while I’m skeptical of Travolta’s ability to play a fast-and-loose action hero, I have tremendous faith in Luc Besson as a writer/producer of fun action movies. Solidly on board, solidly planning to go see the movie they’re promoting, there’s still no way I’m ever going to become a fan of From Paris with Love on Facebook. Or–likely–any other movie on Facebook. For one thing–whether I become a fan or not has nothing to do with whether my friends go see the movie. If they haven’t decided one way or another on it by this point, my becoming a fan is going to amount to a drop in the ocean. Secondly, I have no interest in helping some viral marketing firm (“We get u lots ov fans!!!11!”) get a higher bonus because they hit some fan threshold. The obvious disconnect between the people who actually make the movies and the people who promote them just astounds me. What kind of ads do I want to see? Here are 7 ads I would’ve clicked on:
- Ask me if I’m planning on seeing the movie in theaters. If I click “no,” you can tailor future ads towards your stronger “change someone’s mind” content instead of showing me the same thing over and over and over again. If I click “yes,” you can start showing more interesting ads that might eventually get me to become a fan. (To be fair, I’ve seen polls on movies–but they’re usually some asinine unrelated question written by a marketing intern).
- Don’t promote the movie itself–promote the people within the movie. Had this ad said something like “Become a fan of Luc Besson,” I probably would’ve clicked it in a heartbeat. I don’t even know if he has a fan page, but (assuming he does) that gets any of his future marketing material right into my stream. Becoming a fan of an actual person says something to my friends, while becoming a fan of some movie that just came out says I’m gullible and pay too much attention to ads.
- Build a Flash game for the film (and hire an indie flash developer to do it–there are lots of us) and promote the From Paris with Love game.
- Link to an interesting article on the Film (Digg does a great job of this)–a behind the scenes article or an interview with John Travolta. Something more engaging than “please please pay attention to me.”
- Instead of a canned one-sentence synopsis, just put in a bite-sized piece of trivia with a “like” button. We call them “nuggets” on ShowtimeFu, though we’re a little behind in entering them. A “like” is much less of an investment than fanning something, and I’m much more likely to use them.
- Give me a link to add a similar movie to my queue on Netflix. “Get ready for From Paris with Love by watching Taken”
- Now that I’m 5 or 6 steps down the funnel and I’ve had plenty of positive interactions with your campaign… now is the time to ask me to become a fan of the movie. Don’t just give me marketing drivel, though–remind me of how into the movie I am: “You’re going to see it in theaters, you’ve played the game, you’ve read the trivia, and you’re already a fan of the cast. Isn’t it time to become a fan of the film?”
Okay, I still may not click on #7, but my chances of responding are probably up around 50% instead of 0%, which is a bajillion-times increase. Funnels are used for all kinds of things on websites, so I don’t see why people don’t set up ad funnels to guide people towards the desired result.
I was moving iTunes onto my second monitor just now (placed to the right of my main screen), and the song playing just happened to fade 100% right as I did it. My initial response was, “Oh crap, what did I do?” Almost immediately, though, the sound went back to the left channel and my confusion waned. This wasn’t some newly unearthed OS X gesture, but merely a coincidental alignment of gesture and result. I think the fact that my brain created that causality speaks volumes about gesture-based operating systems in general, though.
Though there are lots of other reasons why I switched to a Mac (the ease of web development being chief among them), but the biggest difference in my mind between Windows and Macs is Cupertino’s love of gesture-based interfaces (which I share). My last Windows machine was a small 8″ tablet running tablet XP–the form factor was perfect for me, but the touch as an interface was way behind the mouse. I build quite a few little interface prototypes in Processing at the time, but there really wasn’t a way to take a small little self-contained java demo and push its conventions onto the OS as a whole (I’m certainly not an OS programmer).
Between the built-in gestures in OS X, the iPhone, multitouch trackpads, and the new multitouch mouse, Apple is kicking Microsoft’s ass on the gesture front. Surface and the Courier are promising, but neither of them are exactly nearing the consumer market at this point. Why not build a touch controller for the XBox? Something small (maybe, uh, Zune sized?) which could act as a secondary display for inventory or controls. There’s nothing stopping them from doing this, and assuming it was available to XNA developers this would instantly get me interested in building more games for the platform (the Zune requirement would mean even less people would buy them, but heck–no one’s buying indie games anyway).
There are rumors swirling that the new Apple tablet will have somewhat of a learning curve, so I’m hoping it’s some kind of new gestural interface. Since it’s not being unveiled for another couple of days, I thought I might as well fantasize a little about my ultimate tablet device:
- An 8″ convertible multi-touch screen with a physical keyboard (I know the Apple won’t have one, but I think an 8″ keyboard is about the smallest still-functional keyboard–and it blows away any virtual keyboard I’ve ever used)
- In lieu of a physical keyboard, a way to dock the thing to a physical keyboard for extended typing.
- An IR emitter with a rich interface for controlling the TV (and a cloud-based Tivo would be nice, too)
- I’d love to be able to just “fling” content from a tablet PC onto a desktop when in blue tooth proximity. Just grab the file, do a little fling gesture, and the file magically lands on the other computer’s desktop. No cords needed.
- iPhone tethering for internet access on the go–or just toss in 3G to the device itself
- The same compass/accelerometer technology currently used in the iPhone.
- A system for slaving the device to a full computer for use as a tablet-based input device. I can’t count how many times I wished I could plug my tablet XP machine into my full desktop running Photoshop to do a quick sketch. Actually, this is dreaming small–I want any piece of hardware to be able to take control of the thing and use it however it wants. Alarm clock dock? Sure. X-Ray machine? Sure. Car dashboard? Sure.
Fingers crossed for Wednesday.
Winners for the Batman: Brave and the Bold game contest were announced back in August, but the individual games were released one-a-week for the 10 following weeks. My game, Plastic Attack! (play it here), launched some time in September, right as I was on my way out to the East Coast for a couple of weeks. Now that I’m back and things are somewhat starting to settle back down to normal, I thought it would be fitting to go back and take a deeper look at the game from start to finish.
The Prototype and the Pitch
When Mochi announced a pitch contest back in March, I was already knee-deep in code for other projects. I had plenty of prototypes lying around, though, so I dusted off one I’d been meaning to expand and built a simple HTML page explaining my pitch. If you scroll down on that page, you’ll see a simple mechanics demo I built in Processing one night while I was at Georgia Tech. The idea was to do a simple platformer starring a ball with realistic squash and stretch animations. As you can tell from the demo, the ball can’t just “jump”–it first contracts down a bit and then flings itself upwards. The other balls were there simply to give the “main ball” something to bounce on, but even there you can see the core idea of “bouncing on things that are destructible.”
The thing I’m most proud of with Plastic Attack!, though, is how similar the end product is to the pitch I delivered. I knew there was a fairly quick turnaround (roughly two months from start to final submission), so I didn’t go crazy. Knowing how much I wanted to deliver was absolutely essential for such a short timeline, and it made it easy to fend off feature creep and even cut some features that would’ve taken too long to polish properly.
Between the time I submitted my pitch and when the “production” phase of the contest actually started, I knew I needed to refine my workflow if I had any chance of finishing on time. Filler 2, though I like the end result, was a jumbled mess of code–after all, it was first time using “real” Flash and not just pure actionscript. To that end, I was able to squeak out Polar Games: Breakdown in April and lay down a fair bit of code that is now sort of my “stock” engine for handling things like data storage, screen management, and other useful bits. The first alpha of the game was pretty rough, though large pieces of the final game were in place: a complex keyboard input manager, a randomly generated “level” (which isn’t always “beatable” in the demo below), parallax scrolling (up & down), a 2D camera system, and a key-sequence finale. Having planned to use canned Batman animations, the only thing missing (well, the biggest thing missing) is actually the notion of squash/stretch from the original mechanics demo.
After playing the Alpha, the Warner Bros. representatives got back to me with pretty much the best idea ever: instead of trying to shove Batman animations into this game, why not use Plastic Man and stay closer to the original mechanics demo? Brilliant! There’s something to be said for working with established IP–these guys really knew their content. That one piece of advice completely turned the game around for me–not that I would’ve mailed it in with Batman animations, but using Plastic Man realigned the development to be exactly the game I wanted to make. I set out to do just that.
As soon as the alpha was a little more polished, I abandoned the notion of a random level generator entirely. The results just weren’t good enough to warrant spending more time on it, so it had to go. Though it looks like a platformer, in my head the game was supposed to play more like a racing game–where track knowledge is a key component to success or failure. The levels were constructed in such a way as to allow the player to sprint from start to finish, with occasional breaks (like the two-bounce platforms) thrown in to add difficulty. I ended up building ten levels which could be played independently (each taking ~35 to 45 seconds to complete) for medals and a “Marathon Mode” which required you to get through all ten as fast as possible (with deaths resetting you to the current level).
After doing Filler for the XBox, I was really in a “controller” frame of mind. I wrote a KeyboardManager class that basically turns it into a game controller. When you initialize it, you take any keys you like and assign actions to them. The keyboard state is polled during the game loop and builds a corresponding array of everything that happened: new keypresses, keys released, and keys still down. I liked how it worked so much that I made most of the menus respond to keyboard input on top of the usual mouse stuff for buttons. A nice side-result of this approach is that most of the platform code is fairly platform-independent. It would be fairly trivial to take my XBox controller code and plug in into the platforming code with very little effort.
What Went Wrong
Throughout the production of the game, there were only really three curveballs. Soon after reviewing the Alpha, they mentioned that the resolution had to be 688×375, not the 640×480 I was building. The proper resolution was actually in the original email, so it was totally my fault. Much of the features parallax scrolling, how high you can jump, etc. had been tuned to 640×480, so that took a bit of retooling. I should have made it liquid to begin with, though, so in the end it actually improved the underlying code.
The second problem was my grandiose idea of squash and stretch. The problem with forcing the character to press down before allowing a jump is that it created roughly a 100-millisecond delay between when the spacebar was hit and when the character actually left the ground. The Warner guys didn’t like it, so they asked me to cut it. I defended my bouncing, but what I ultimately realized is that it wasn’t so much the bounce code that was the problem but the overall difficulty of the game itself (by this time several players had mentioned that they couldn’t beat the first level–more on that below). There were two options to simplify things: re-design all the levels from scratch to make them easier, or make the controls more responsive. Given the tight schedule, it was a no-brainer. The Warner guys loved it without the delay and I got to keep working on other stuff.
The final issue had to do with high scores. Towards the final Betas, I learned that the game would need to have a single “end point” with one high score. What I had was 10 levels (each with their own “low score”), and several Marathons (my original build had a straight runthrough all 10 levels, a first-5 set, a last-5 set, an odd set, and an even set). Converting the time into a point score is trivial–just take a “max” value and subtract the player’s score. Getting the game down to a single exit point, though, was slightly more worrisome. I ended up cutting all but the “full” Marathon (all ten levels in a row), which I think might’ve been a mistake (I don’t know what the right answer was, either, though). The barrier for entry on submitting a high score is just insanely high in the final build: before playing Marathon mode, you must “complete” (get at least a bronze medal) all ten levels. Though I can beat any of them in under 45 seconds, watching a few first-time players try it I’ve seen them take up to 30 minutes to beat the first level (far longer than a normal user who wasn’t playing as a favor would likely give the game). Assuming that they do finish all ten levels, they then have to finish the marathon itself–my best time is somewhere around 5 minutes, but my worst times are in the 15-20 minute range. That’s just way too long to have to play before being allowed to submit a score.
Besides the three production hiccups, I’ll also toss on a more philosophical issue summed up by a game riddle:
Q: How far can Mario jump?
A: The width of the hole in front of him.
Technically, Mario can jump further if he’s sprinting, but I think the point comes across. In most platformers (including the 2D Marios), a hole is merely one obstacle of many. Jumping is important, but it’s a binary decision. When there’s a hole, you jump over it. You don’t have to think about the hole too much–the combination of pressing the jump button and holding forward will carry you over it. The jump length in Plastic Attack! is dynamic–you move forward only as long as you hold forward down. The amount of time you stay in the air is fixed, and the default length of the jump (assuming you hold forward) is equivalent to the double-jump (it will clear two floor tiles). Whereas the “standard” platformer makes the single-jump the default action, in Plastic Attack! it’s really easy to overshoot your target (and fall to your death). Though I found it very intuitive to just ease off the forward motion when I get to where I wanted to go, it’s actually a LOT harder than I originally thought it would be.
Designing for Failure
My favorite thing about the game, though, is how hard it is. Wait, what?
I like hard games. I don’t want every game to be hard, but every now and then I thrive on a little challenge. Though I may have gone a little too far, difficulty factored into the design of the game from the very beginning. One of my absolute biggest pet peeves when it comes to games like this is what happens when you fail. Typically there will be a transition to a new screen, perhaps with some exposition or animations on how you’ll never save the universe if you keep falling to your death. At that point you’re given an option to give up or try again. In a good game, you can just press space to continue. If you really want to piss me off, you’ll require that the user click on one of the buttons to continue. I’ll put it in bold, because I think it’s that important: if your game is played with the keyboard, there’s no excuse for making your player switch to the mouse to continue playing. This is the number one reason I stop playing a keyboard-controlled Flash game, and I just don’t understand the reasoning behind it. High score submission? Fine, use the mouse. Main menus and instructions? Fine, use the mouse. Once your player commits to the gameplay part of your game, though, do them a favor and let them hang out there on the keyboard until they’re sick of playing.
More than just letting them stick to the keyboard, I wanted to design for failure. In fact, I want my players to fail. If they can play through a whole level the first time and get a medal, then I feel like I did a really crappy job designing that level. This goes back to challenge–I’ve played too many games with 50 or 100 levels that I never finish. If I don’t get a level that I fail on before I get up to level 10 or 15, I’ll stop playing a game. If there’s no difficulty, it’s just an activity–I might as well flip on the TV at that point. It’s by overcoming those failures that getting a bronze, a silver, or a gold medal actually assumes some meaning. There’s a chance that I’ll turn off a lot of players who get frustrated before getting that first medal, but my hope is that those who make it through will feel like they’ve accomplished something.
With my mini-rants out of the way, back to what happens when you die. Because dying happens so much, I felt like the process of restarting a level should be absolutely effortless. No animations that will get annoying by death #137, no waiting for recap screens to finish–I decided to just go ahead and restart the level. If the player doesn’t want to play any more, they’re most likely going to close the window anyway. If they do want to back out, they can always pause the game and exit to the main menu from there. Because the “cost” of failure is so low, I was actually pretty satisfied with the final level of difficulty.
What Didn’t Make It
There’s only one major feature that I ended up cutting: checkpoints. I didn’t want to just do checkpoints, though, I wanted to do checkpoints right. Because the game is essentially a really hard racing game, several playtesters suggested that I add checkpoints to smooth out the difficulty curve. Instead of restarting the whole race from scratch, you’d merely go back to the last checkpoint. Being a racing game, though, I would want to penalize players in some way–tacking on penalty time or just letting the clock continue to run. While this would be a blessing for beginning players just learning the levels, it completely runs afoul of my “design for failure.” Any expert player is going to reset the race as soon as they take any kind of penalty. If you’re going for a high score, there’s just no room for error. By simplifying the game for beginning players, I would’ve reintroduced the “annoying death loop” for expert players: mess up, pause, reset, start again–mess up, pause, reset, start again. In the end I just couldn’t do it.
Now that I’ve had time to think about it, my solution would be to actually commoditize checkpoints within the game world. Instead of having fixed checkpoints, they would be carried with you at all times in limited supply. For a ten-level game, you’d have 10 checkpoints to use… “ever.” If you need five checkpoints to make your way through one of the levels, those five checkpoints would be “left” in that level permanently. Should you manage to play through again and use only three checkpoints, it would free up two of them back into your pool of checkpoints. A beginning player could use as many checkpoints as necessary to beat a level and then work on refining their approach and reclaiming their “lost” checkpoints before moving onto the next level. A pro player, on the other hand, wouldn’t need to drop any checkpoints and thus could play through the entire level without needing to reset should they happen to fall. A similar mechanic was used to great success in a game called SeppuKuties a little while back.
Ultimately I didn’t have time to finish planning and balancing the feature during the hectic production schedule, so I ended up cutting it altogether.
I took a break from the world of bouncing to get the XBox version of Filler out, but now I’m in full production on my own version with an artist friend. The game will be called Free Bouncing (think free running). I still have a lot of decisions to make with respect to things like microtransactions (vs just ads) and user generated content. Check out the teaser images below:
The night before hopping on a cruise last month, Filler finally went live for the XBox (September 13th). Coming up on almost a month of data, I wanted to take a look back at the XBox version’s development process and comment on Microsoft’s Indie Games in general. I actually had a solid prototype working on the XBox over a year ago, before the service even launched. I had way too many other projects on my plate, so the XBox version kept getting pushed to the back. After finishing up the Batman: Brave and the Bold contest game in early July (I’ll do a post-mortem on that one as soon as I get a thumbs up), I felt it was finally time to clear the XBox version from my to-do list.
From each time I’d worked on the game for a week or two at a time, there was quite a bit of code in place. I’d completely stripped down APE (Actionscript Physics Engine) and the original Filler codebase to be as abstract as possible, then moved that code directly into XNA. I won’t say I got it 100% MVC, but it was pretty damn close. The majority of work, then, was all about building up the actual display and menus for the XBox version. Building the interfaces was pretty easy–though the lack of an interface builder means it’s a lot of “tweak, compile, check, and repeat”–not so dissimilar from coding Flash games in pure AS3.
Having played tons of Indie Games for WorthThePoints, I also had a pretty good list of things about the service (and the XBox 360 in general) that bugged me. Top among that is the prevailing idea that one profile directly maps to one human player. While I know why they did it that way (more Gold accounts), I personally think the profile system in the XBox is terrible for multi-user households. Content is attached to profiles instead of machines, which means we’re always logging different profiles in and out to figure out which profile has the proper permissions or features unlocked in a given game (that’s directed at you, Rock Band). Because Indie Games are even more rigorously locked to single profiles, I wanted to build my own system which would function more like the “save” slots of the old SNES and Playstation games I used to play.
Besides adding a co-op multiplayer component, I really didn’t want to just release “another Filler” for the XBox. The original Filler was only tuned through about level 15 (the highest I thought anyone would make it), so I was totally unprepared when people were up in the 60′s and 70′s a couple of days after I released it. Besides the physics breaking down, the difficulty of the game itself completely plateaued past around Level 15. Both the number of lives and the number of balls allowed spiraled way out of proportion to how many were actually needed to beat a given level. For Filler 2, I tried to correct this by combining the lives and balls into one value. The problem with this approach was that experienced players need way less balls than new players. Starting the game with 10 balls was reasonable for a first time player, but it gave expert players such a huge cushion to work with that there was never really any danger in losing.
The limit on how many balls could be placed was mostly put in place to put players from “cheating” and simply filling up the board with hundreds of tiny balls. To move towards making that the core win/lose state, then, was promoting a feature that was only added for convenience’s sake. For the XBox version, then, I wanted to get back to the notion of lives while thinking of a better solution to limit how many balls could be placed on screen. I tried lots of things: a power meter that depleted, holes in the floor that let small balls slip out, special enemy balls with a variety of powers (including popping small balls).
While playing with the notion of special enemy balls, I actually stumbled onto a pretty fun game mode which I may code up and release as a standalone version at some point. One of these special balls had erosive powers–every time it bounced into a filler ball, that ball would shrink a little bit. It was this mechanic which finally provided the difficulty curve I was looking for–though not as originally implemented. By making all the filler balls shrink at a constant rate (like filling, the “shrink” rate is proportional to the area instead of the radius, which means big balls shrink slowly and small balls shrink quickly), I actually solved three problems for the price of one.
The “fill the board with small balls” strategy became worthless–before the screen is even half way full, the first balls dropped in this manner start to “pop” and take lives away. Second, even when playing in the “proper” manner the new shrink rate adds a time-crunch component which was missing from the first two versions of the game. Most importantly, the shrinking balls smooth out the difficulty curve–they’re practically a nonfactor in first ten levels and don’t really start to have a major impact until around level 15… where the difficulty was previously plateauing. From a pure gameplay point of view, then, I firmly believe the XBox version of Filler is the most well balanced version to date. If I ever do another Flash version of the “core” game (and not a spin-off), it’ll be nice to have that part of the equation “solved.”
I submitted Filler to peer review for the first time on August 8th. It would go on to fail twice–both more for quirks in the framework than what I’d consider bugs on my part. The SpriteFont class takes an optional parameter when instantiating it, a single character which is used in the event that your code tells the SpriteFont to render a character which isn’t contained in that font (i.e. a character with an accent on it). Rather than doing something sensible like defaulting to a space (or simply rendering nothing), a call to render one of these characters causes the whole game to crash. Again, this is something that’s part of the XNA framework and not something inherent to C# itself. The fix? Adding a ‘-’ to the initializer for my fonts, which took about 30 seconds. The penalty? Besides the five days it spent in review before the crash was found, it had to spend another eight days in review “jail.” The published cooldown for a rejection from peer review is seven days, but your jail time doesn’t start until the day after you pull it from peer review (or get rejected, I assume). So if you pull it at 5 AM, it’s practically an 8-day wait.
After resubmitting the game on August 21, it took only a day for another crash to show up. If you try to open the marketplace menu with a silver account (i.e. a non-paying XBox Live account), the game crashes. All the accounts on my box are Gold, so I never even thought to create another one to test from. For a framework that does its best to handle all of the transactional details for you (trial modes are automatic, purchases are handled completely outside the game), it boggles my mind that the framework itself doesn’t pop up an alert with something to the effect of “You must be a Gold member to access this content.” The fix? Testing to see if the acting player is Gold or not and popping up an alert if they’re not–about five minutes of coding. The penalty? Another 8 days in peer review jail.
I’m not trying to say I’m completely without blame–if I’d spent another couple of weeks reading every detail of the framework documentation I might’ve been able to find these crashes before submitting. And I don’t think the “7-day” jail is a bad thing. The idea of it–to prevent people from dumping buggy games onto the service with no QA is noble, but I think it does more harm to well-intentioned developers than the “lazy” developers it was meant to stop. A better system might take into account the severity of the bugs and the submission history of the developer.
I was traveling when Filler failed the second time, so I was unable to submit again until September 2nd. Right around the time I submitted it for the last time, I posted some of my thoughts on the review process to the XNA forums:
What are essentially two framework quirks have cost the game nearly three weeks (it usually takes a few days before anyone bothers to review). These are mistakes I’ll know to look for next time (if I choose to continue developing for XNA), but the end result is that the submission process is unnecessarily cumbersome to first-time XNA developers–the very people Microsoft should be bending over backwards to court! I hope that there’s enough backlog some day for MSFT to actually hire someone to wade through it–a community relations job or a full-time tester.
This may sound douchey, but I have absolutely no interest whatsoever in playtesting or reviewing a game that hasn’t come out yet. I honestly believe I add more value to XBLIG by spending my time on development of new games and reviewing published games than by wading through unpublished games. Zman mentioned how few people are trying to make XBLIG a real business, and that’s because no one expects EA to playtest Call of Duty before it’s released (especially Activision!). You do your best to make your game, get it bug free, submit it to MSFT. If there are bugs you release patches.
Those sentiments were met with nearly universal scorn by the “main players” in the forum, but I stand by them 100%. At times it seems as though the Microsoft employees and most of the MVPs which frequent the forums (though certainly not all) have had rose-colored glasses permanently attached to their heads. There seems to be an overwhelming belief that if they hold hands and sing “Kumbaya” for long enough that the community will magically come together in a supporting environment where everyone does peer reviews. By voicing my opinions, though, the most common response was “don’t expect me to ever review one of your games. Good luck getting anything released.”
They claim that there are legal reasons Microsoft itself can’t approve apps, but that argument just doesn’t hold up–Apple has approved almost 80,000 apps since the XBox Indie Games channel launched (last November), and all without peer review. After pretty much giving up on ever getting the game out, some more reviewers checked it out while I was on the east coast and it finally got approved on September 13th–over a month after “finishing” the game.
Sales so far have been pretty tepid, which hasn’t been too surprising given other games’ lackluster sales. Though there are still a few days left, it looks like the game will sell less than 100 copies in its first full month (currently sitting at 83 with 4 days left). More disappointing than the actual sales, though, are the trial downloads: in almost a full month, only 2,520 trial copies were downloaded. 2,000 of those were in the first three days (while on the New Release list). In the last week, daily downloads have ranged from 2-6 trials per day. I’ve stuck with it for a couple of years now, so clearly I’m a fan of Filler’s gameplay–but I certainly don’t think it’s the greatest game out there. Still, it’s rated in the top 20% of all games on the service (at least, last time I checked). For sales to fall so flat so soon tells me two things:
- Though I considered the work I put into the challenges, multiplayer, and profile systems enough to bump the game up from a $1 game to a $3 game, I get the sense that players (and customers) don’t actually give a crap about those features and would rather just have the core gameplay for $1.
- As an ecosystem, the Indie Games Channel only has enough traffic to support the top 25 or so games in the system. The iPhone has enough users that even an “average” game can see several purchases per day, whereas an “average” game for the XBox will be lucky to get 2-3 trial downloads per day.
The breakout success of “I MAED A GAM3 W1TH Z0MB1ES!!!1″ has shown that there’s a place for content without any “extra” features at $1. If I had to go back and do it again, I would’ve just released the game without profiles and challenges months ago for the lowest price point. Extra work on the game doesn’t really get you anything on the Indie Game Channel (versus what we’re seeing in “Premium” flash games that can command user payments), so if I release more games for the platform they’ll definitely fall within that $1 “throwaway” style game.