At long last, Filler is now available on iTunes (you can see my little splash page + iTunes link here) for $1.99. I’ve never outsourced anything before, so it was a bit of a learning experience. I ended up working very closely with the team at ChaYoWo–they’re probably happier to be rid of my long bug reports than they are to actually launch the game (I kid). I’m very satisfied with the final product–even if it doesn’t sell a single copy, there’s a certain joy in being able to play my game wherever I go now. There are a couple of interesting things that happened during the development of the iPhone version.

The first thing I usually hear when people see I’m working on an iPhone version is that I should make it tilt-enabled so you can move the balls around. The problem is… that makes the game stupid easy. It’s not really that hard of a game to begin with (but man is it good to kill 5 minutes while you’re waiting for a bus…), so adding in more mechanics to simplify things just seemed like the wrong direction. Another idea I had was to use the tilt to move around the cursor, and have a button for making filler balls. We actually coded this one up, but… uh… it was terrible. In the end we decided not to use tilt and to keep the gameplay closer to the original Flash version.

One thing I noticed while playing early builds (which I also noticed while playing various clones that are already on sale) is that your fingers really do get in the way of dragging the Filler balls around while they inflate. Most of the strategies for the Flash version involve creating balls near the top of the screen and then using them as shields while they fall. “Finger-blockage” is at its worst when your finger is at the top of the screen, though, greatly diminishing the usefulness of those strategies. While playing those early builds, I did something radical: turned my iPhone upside down. Success! Sure, the balls are floating up instead of falling down–but man it was great to see the whole screen. Asking players to flip their phones upside down is just silly, though, so I did the sensible thing and reversed gravity.

ScoreCaching

While the ChaYoWo guys were coding the app to my demanding specs, I got to work on another integral piece: ScoreCaching (Update: ScoreCaching has been killed). Most of the iPhone games I’ve played with online leaderboards do just that–global online leaderboards. I wanted a little more than that, so I figured I might as well build it myself. ScoreCaching combines the idea of online leaderboards with geographic location (think Geocaching). Instead of comparing your scores to everyone in the world, why not compare your scores against everyone nearby? Even better, why not leave your scores behind as a mark of your achievement? Just as people used to line up at arcade boxes with the hopes of leaving their initials in the number one spot, ScoreCaching will (eventually) allow players to mark specific places. What’s your high score for the Golden Gate Bridge? What about Times Square? How about the pub down the street? Those features are a little ways out still, but for now you can compare your scores with your friends and those around you.

Filler 2 (Flash)

When Shockwave offered to sponsor Filler 2 as a three-month exclusive, it seemd as if the stars were aligning perfectly. That would give me extra time to finish up the iPhone version, ScoreCaching, and the XBox Community Games version (whoops!). I didn’t quite finish the XBox version (though I did write a hell of a lot of reviews over at Worth the Points), but Shockwave’s exclusive is up and now the rest of the internet can finally enjoy Filler 2. Kongregate, the totally-kick-ass sponsor of the original Filler, is reprising its role for the second go-around. You can play it over on Kongregate here or play it on my site with the link on the sidebar–I’ll start spreading it around the rest of the net sometime next week. If you run a flash portal, feel free to snag the SWF off my site (the one on Kong is site-locked until I verify it’s totally bug-free). If you’d like to license the game for your site (ad-free), drop me a line at learnyourabcs@gmail.com.

What’s Next?

On top of everything else, I’m also one of the developers in Mochi’s Brave and the Bold Contest. A $4k (minimum) payout is okay, but let’s get something straight–it’s freakin Batman. I watched the original Batman cartoon every day for years as a kid (I was a Marvel kid when it came to comics, but the Batman cartoon was awesome). Getting to develop an original game concept with one of my favorite characters–that’s a sweet deal.  I’ve also got a handful of other finished prototypes in the pipe that are currently on hold until I can clear some of this development logjam.

As always, stay tuned to this space for interesting facts and figures on how everything is doing.

The game’s main game mode was always going to be puzzles. I’d hoped to do 100 before releasing the game, but writing the puzzles by hand just proved too time-intensive. Forty puzzles are in the game now, and assuming the game doesn’t tank completely (*cough* Nibblets *cough*) I’ll think about continuing on with the final 60 puzzles. In the meantime, though, I hit on the idea of adding a “Daily Puzzle.” Using the date as a random seed, all players will get the exact same puzzle each day. There’s no guarantee that the puzzles will be solvable (most won’t be), but hopefully that adds a little more strategic competion than the longer, more-luck-based Score mode.

The basic mechanics for Score Mode are really not that different from Collapse. I wanted to break away from using a game timer, though, and create something more meditative. Instead of having new blocks come “up” every time a timer finishes, I just have new ones fill in infinitely. The polar bears “judge” your every move, and based on how many tiles you clear will either give bonus health or take away life. As health fades from 25 down to 0, the sky darkens and the music slowly gets quiet. Once you hit 0, the whole thing goes red and you’ve got 5 turns to get back into positive territory before the game ends. As you clear various colors, the meters on the right side of the board fill up. Clicking on them clears all tiles of that color, which allows you to build some pretty monolithic color groups. This transforms the mechanic from a frantic “click any group of 3″ to something a little slower, where the goal is to methodically build up giant chains while keeping an eye on your health.

To play the multiplayer version, you’ll have to check the game out on Whirled. The multiplayer mode plays much like the Score Mode, save for the fact that the board is split into four quadrants. Each quadrant is the home base of one player (empty seats are filled by AIs), and players take turn making moves. Tiles cleared in your own quadrant replenish your health, while tiles cleared in an opponent’s quadrant take away health. Every 10 rounds, a damage multiplier increases the amount of damage players do to each other. Using one of your “clear all” powerups doesn’t count as a turn, meaning you can set up an epic clear to heal yourself or attack your opponents. If your life falls to zero (or lower), you will be unable to deal damage to other players until you get your life back above zero.

Whether the game is a hit or not, building it has been incredibly valuable. The first few games I did were in “pure code” and compiled with MXMLC. Filler 2 was the first time I used Flash, and the process was… rough. This time around I had a much clearer picture of what I wanted to accomplish in Flash compared to what I wanted to do in raw code, and the actual development process was a breeze on this one. Pieces of a generic Flash game engine (and, just as importantly, a build process) are beginning to fall into place (sound and data managers, game boards, UI classes). Prototyping is still my favorite part of the game building process, so the more I can shrink the window between prototype and launch the happier I’ll be as a developer. =]

I’ve been a little quiet lately–and crazy busy. I’ve got a few new projects to announce in the next few weeks, but the first of the bunch just went live. As of yesterday morning, Filler 2 is officially live on Shockwave! I started working on a new version in October of last year, and I think it’s fair to say a lot more time has gone into this one than the original. Changes include:

• 100 Challenges, most of which allow you to jump right into a specific game scenario.
• Optimized physics to support more balls onscreen in higher levels.
• I rolled lives and balls into one, which was a point of confusion for some people in the first game.
• The bonus timer is gone.
• Improved graphics, with the ability too choose your ball and background.
• I added the ability to freeze time–pressing “space” will freeze all the bouncy balls and make you invincible for short bursts. Your freeze time is replenished each level, and you get roughly 1/4 of a second per level.
• When a ball pops, it now “explodes”–repelling any nearby balls. This can be used strategically on later levels to create void spaces.
• There’s now a hard level cap at Level 50.
• Past level 25, the bouncy balls will pick up speed every level to make things more challenging.
• There are three difficulty settings:
  • On easy, you can’t die. This is more of a “relaxation” mode.
  • Normal is, well, normal. You get two more balls each level and limited amount of freeze.
  • Hard is closest to classic Filler. There’s no freeze time, and the balls are a lot more limited than the first game.
• The game will automatically track some basic stats for you (average score, highest level reached, etc…).
• A self-destruct button will allow you to end the game if you’re read to submit your score.

This game also marked the first game I’ve ever done in Flash (as opposed to pure AS3, compiled with the Flex SDK). The vast majority of the code was still done in class-based files, but it’s really a lot easier doing menus and “screens” in Flash. My workflow going forwards will likely involve doing all my prototyping with the Flex SDK before moving on to Flash for the “fit and finish.”
The game will be an exclusive on Shockwave until May 3rd–I’ll be able to start distributing it more widely to the other portals afterward. In the meantime–everyone go play it on Shockwave!

It’s my first game for hire. There are definitely some pros and cons to doing it that way. The money is guaranteed whether the game is a hit or not (though it’s unlikely you’ll make a second one if your first game is a total flop…), but there are a couple of caveats. At the end of the day, you’re making a product for someone else–which means the client has the final say on things like art and sound approval. I actually thought this was going to be a bigger headache than it was. Shockwave came to me with a loose concept, but my producer gave me almost total freedom to go in whatever direction I chose.

It’s my first game with “art.” I’m not an artist, and I don’t pretend to be. The end result is that most of my games take on a procedural style with very little in the way of tangible assets. Procedural is great for my own stuff, but for a contract game the polish needs to be amped up a level. To that end, I actually subcontracted out the art assets. Though a headache at times, I’ll definitely do it again for games that warrant it. I’m very good at visualizing exactly what I want, but sometimes communicating that to an artist is a bit of a challenge. I think the end results speak for themselves, though.

It’s my first game with outsourced sound. Unlike art, I’m not totally incompetent at sound design. It just takes me awhile to sift through sound libraries and pick the right sounds. In the interest of speeding things along, I opted to have someone else do the sound for me. I compiled an asset list (though I manged to forget a few, of course) and had a third party do a “sound pull” based on my descriptions of what I needed. The cost was fairly trivial (especially considering I was going to purchase the sounds anyway), but I’ve got mixed feelings on the results. For most of the sounds, I know–if presented with four variations of each of the sounds–I probably would’ve chosen a different one. On the other hand, it may’ve taken me an hour to find the four candidates and choose the “perfect” one. In the end, I got sound effects that fit well enough and saved me hours of toil. I’m a bit of a perfectionist, so I don’t know if I would do the same again (unless under time pressure).

It’s my first exclusive game. Now that the game is out, the exclusivity is actually bothering me more than I thought it would. There are a couple of sites around that I’d consider “portfolio” sites (like my own site, Kongregate, and even Newgrounds) that I would love to upload the game to–not for any chance at winning contests, but more just to gather all my games in one place. That means I’m proud of the game, of course. If it was a steaming pile, I’d be perfectly happy to count my loot while no one ever played it. Aside from those sites, though, exclusivity is a bit of a relief as far as the work-load goes. I’ve done over 15 versions of Filler for various portals (with more coming still!), so there’s a sense that the work never ends. Aside from any bugfixes that need to be done, there’s a definite sense that Boulder Blast is “done.”

It’s my first game with a deadline. The release date for this game was penciled in even as I began prototyping it, which is an altogether different way of working on things. Like most of these “firsts,” I’m sort of torn on whether that’s a good thing or not. I’ve definitely still got the college many-class mentality, and I thrive when I’ve got tons of projects going at once. Knowing that a deadline is looming is great for generating focus, but it also makes the game feel like “work.” I’m much happier (albeit slower) when I can jump from project to project at my whim and go at my own pace. I might be interested in seeing if it’s possible to do a contract game without a work schedule in place (i.e. a “We want this, email us when it’s done” contract). All payment would obviously be presented at time of delivery instead of staggered payments throughout the build process, but I think that would do wonders for taking that “work” aspect and redirecting it back towards “fun hobby that happens to be lucrative.”

Summing up. Between Filler and Boulder Blast, I really feel like I’ve gotten an MBA over the last six months. Filler taught me loads about marketing, negotiations, and the economics of flash games–while Boulder Blast was all about resource management. I’ve got a lot of ideas somewhere in between sketch-on-a-napkin and full-on prototype, but for now I’m thinking I need to take a little time off from game development, put a little dev time into some of my languishing web projects, and get caught up on “fun stuff” like movies and (playing) games.

Note: I shrunk it down so it would fit in this blog pane (I’ve made a mental note to fix that later).  The actual game dimensions are 600×500,  so don’t tax your eyes too badly playing it here!  You can see a bigger version at one of my ugly temporary pages here.
]]> http://www.simianlogicstudios.com/2008/01/11/filler-a-game/feed/ 26 http://www.simianlogicstudios.com/2007/11/09/nibblets-and-the-state-of-flex-game-development/ http://www.simianlogicstudios.com/2007/11/09/nibblets-and-the-state-of-flex-game-development/#comments Sat, 10 Nov 2007 05:38:23 +0000 SimianLogic http://simianlogic3d.com/blog/2007/11/09/nibblets-and-the-state-of-flex-game-development/ I had an idea for a game about a month ago. Normally I just prototype this things, file them away, and move on to the next one (there’s always a next one). I was taking part in the MochiAds beta at the time, though, so I figured I’d put a little more work into it and release it on a few sites. To cut a not-too-long-story short, making games sucks. I’ll qualify that. I love prototyping, but I’ve spent the last month (on and off in my after-work non-girlfriend free-time) essentially adding instruction screens, level selection screens, and high score integration. The actual gameplay (and all 10 levels) haven’t changed at all since my first prototype (which took about 2 hours) over a month ago.

This isn’t to say that I’m going to ever stop making games… because it’s too much fun. I’m not going to hold my breath on the financial rewards coming in from the MochiAds, but it’s pretty cool that I can track how many people are playing across a bunch of different sites (sadly, MochiBot doesn’t work with Flash 9 yet). And once it’s been out there awhile, I can flip a switch and turn all the low-CPM ads into links back to my own site.

Why does doing interface stuff take so long? Well, for one thing, it’s boring as hell. This is the main reason MXML exists… but unfortunately, neither of the two “services” I’m targeting allow it: Whirled (still in super-secret Alpha) and MochiAds. The other that I wouldn’t mind supporting is Kongregate, but they’re not Flash 9-enabled, yet. Perhaps Flex isn’t quite mainstream enough (and by that I mean stupid-simple). Or maybe rather than building more games I should devote some time to developing an AS3-only interface library.
On to the game! I whipped up an ad-crazy embedded version just to test out a couple of other ad mechanics. Or you could go directly to the SWF. The thing runs at 900×400, so I’m not sure how well it’s going to embed below:

This part, I’m convinced, would still work for a pretty cool puzzle game. Here’s where I flubbed it up, though. I thought: “How cool would it be if your pieces kept bouncing around and you could gather them back up?” This is what’s prototyped below. While thinking about levels to use, I suddenly remembered the game Nibbles–a basic snake game I used to play all the time in high school. Written in QBasic, it was essentially my introduction to programming. I found a copy of the code and mostly-faithfully (minor size tweaks were needed) reproduced those original 10 levels to act as a backdrop to the game listed above.

The result? Booooooring. As I mentioned, I think this concept could really have legs as a puzzle game. Instead of a sequence of tokens, seed the board with a bunch to begin with. Make firing a blob permanent (no reclamation) and layout the levels with enough angled pieces to make things interesting. The game then becomes a resource-management/maze-thing–more like the penguins-sliding-on-ice style of games.