Gridshock Mobile for iPhone (with Android on the way?)

by Josh Tynjala

My most recent mobile conversion, Gridshock, has gone live in the iPhone App Store. Unlike Chroma Circuit, Gridshock required some heavier fundamental layout changes, but I think I kept the difficulty balance and speed at a level that’s about the same as the original. I even took some time to add a couple new features.

First, I added the Shock powerup to the mix. When you match five or more lights, one of them won’t disappear. Instead, it upgrades to add the powerup, and it can be matched again. When matched a second time, it will remove an entire row of lights. Very useful when things get fast and frenzied, and the grid has almost overflowed.

On the Options screen is a new setting called “Patterns”. For players who might have difficulty telling the difference between some of the game’s colors, Patterns mode adds a unique and high-contrast shape to each color.

What’s that I said about Android?

On other fronts, you might be interested to know that I’ve had a chance to preview an upcoming version of Adobe AIR for the Android mobile operating system. Adobe’s Ted Patrick recently showed off a few sneak peek Android screenshots, and he includes both Chroma Circuit and Gridshock in the mix.

The only thing I needed to focus on for Android from a development perspective was ensuring that my games would fit well in different screen resolutions. Christian Cantrell’s recent article, Authoring mobile Flash content for multiple screen sizes, has a wealth of information on this subject, and I suggest any Flash developer expecting to target mobile check it out. I was thinking about writing a blog post about multi-screen content myself, but Christian covered all the details I would have, so I recommend it highly.

Start the Discussion

Tuesday, February 16th, 2010

Adobe TV video about Packager for iPhone and Chroma Circuit

by Josh Tynjala

At the end of 2009, I released by my game Chroma Circuit for the iPhone. It was developed using early builds of the Packager for iPhone to be included with the upcoming Flash CS5. Adobe recently met with me to chat about my experience using this exciting new technology.

Watch the video above or over at Adobe TV. Now, if you’ll excuse me, I have a couple other mobile games to hurry up and finish.

Start the Discussion

Monday, January 18th, 2010

Indie Flash Game Development: A 2009 Year-End Retrospective

by Josh Tynjala

In early 2009, I came up with an idea for a Flash game. At the time, I had enough saved up to take a short break from regular work, and I decided to try out game development on my own for a little while. That first idea eventually became Chroma Circuit, a cool little puzzler released by my new company, Bowler Hat Games. Since then, I’ve released two other free-to-play Flash games, one iPhone game using Adobe’s upcoming Packager for iPhone in Flash CS5, and I’m working on another iPhone game as I write this. The other day, I realized that I started creating games in January, right at the beginning of the year. With that in mind, I thought I’d take a look at how I did, financially speaking, in my first full year as an indie game developer. Get ready for some numbers!

Time Breakdown

To start, let’s look at the time I spent on various projects in 2009. Unfortunately, it wasn’t all fun and games. Though I had a decent savings to get me started, I needed to refill my treasure chests mid-year, and that meant time away from game development. Here’s a pie chart to visualize the breakdown:

Time Spent on Projects. 33% RIA Contracts. 13% Game Contracts. 50% Bowler Hat Games. 4% Time Off.

As you can see above, I spent six months working exclusively on my own games full-time. For a month and a half, I worked on some contracts that involved developing games for other people (the next best thing to working on my own games, I suppose). In addition, I spent another four months on contracts building some Flex RIAs (non-game development, obviously). Finally, I took a couple weeks off in December to relax and enjoy the holidays.

As we take a look at my income next, please note that I will omit the amount I earned from things other than developing games. I want to focus more on what I earned specifically as a game developer rather than as an RIA developer. Regardless, I’ve mentioned this additional income because many game developers take the same approach: contract work funds the things we really want to do. Though I won’t give you specific numbers about the non-game income, I will note that well over half of my overall income this year falls into that bucket. In short, games did not pay the bills this year.

Quick Income Breakdown

In total, games earned me $29,413 USD in 2009. This year, I had five sources of income from games: primary sponsorships, non-exclusive licenses, advertising, iPhone game sales, and custom game development for clients. I’ll explain each of these below, for those who might not be familiar. However, let’s start with a simpler comparison to make one important point.

Income. 58% Game Contracts. 42% Bowler Hat Games. Time. 20% Game Contracts. 80% Bowler Hat Games.

As you can see from the chart on the left, about 58% of my game-related income came from contract work. Once again, even focusing specifically on game development, we can see that contracting is still where the real money is. Big clients pay big money to bring in developers to get their projects done. For comparison, the chart on the right shows the amount of time I spent on each. As you can see, the majority of the income from games comes from only 20% of the time I spent on them. If I were only interested in the size of my paycheck, I think it should be obvious which type of work I’d want to choose.

Detailed Income Breakdown

Now, let’s go one level deeper. The games I built entirely under the Bowler Hat Games banner earned me $12,413 in 2009 with six months of work. Assuming I didn’t live in the San Francisco Bay Area, I might have been able to stick to games the whole year with only a small loss, hoping to make up for it as revenue continues to grow in 2010. However, my current location is pretty expensive, so focusing on my games exclusively is still not possible yet.

Bowler Hat Games Revenue. 54% Primary Sponsorships. 21% Non-Exclusive Licenses. 20% Advertising. 5% iPhone Sales.

The majority of revenue comes from primary sponsorships, which are sold to game portals who want their branding and links to appear in any distributed version of a game. Sponsorships help them bring traffic back to their sites. They usually pay an author a lump sum for this privilege. Sometimes, sponsors offer performance incentives so that very popular games can earn more, but usually, a sponsored game only earns money from the sponsor once. I found this form of revenue useful to start out, but I’m not sure how often I will pursue it in the future. I’m starting to feel that they make it harder to build my own company’s brand because my games promote the brands of others so strongly.

Next in line is the non-exclusive, site-locked license, which allows game portals and virtual worlds to customize a game by adding their high score APIs, removing advertising, and making other small changes. By getting the game site-locked to one website (in other words, no distribution), they can offer a quality game directly on their portal for a lower price than sponsorship, but without the audience reach that a sponsorship offers. A non-exclusive license can earn as much or more than the primary sponsorship in the long run because you can sell as many licenses as you want. Generally, it only takes 2-3 hours for me to whip out a customized version of one of my games, and I earn more per hour for this work than what a primary sponsorship gets me for the original game.

By the way, FlashGameLicense.com provides an excellent service for Flash game developers to connect with publishers and sell sponsorships and licenses. I found primary sponsors for all three of my games there, and many of the portal owners that made non-exclusive deals with me initiated contact on FGL.

Often, advertising earnings can be a pretty low percentage of a game author’s revenue. However, my game Gridshock has found itself among the top games on the popular MindJolt portal (and Facebook app) for some time now, having received over 16 million plays overall as of the time of this writing. My all-time eCPM for all three games combined right now is $0.26 from MochiAds, though I’m showing a custom ad in Chroma Circuit right now to promote the iPhone version so that’s not earning anything at the moment. Gridshock alone is a tiny bit higher, at $0.28. I also use Google AdSense on the Bowler Hat Games website for some extra ad revenue, but their Terms of Service are mean, so I can’t really share anything about that.

Finally, there’s my iPhone game. I released it in October, and, as you can see, it hasn’t brought in much revenue, relatively speaking. The App Store isn’t an easy win these days, and that’s pretty much what I expected. However, Chroma Circuit has always done a little poorly compared to my other two games (other than the larger-than-average primary sponsorship), and that means I expect those to do better in the App Store once I finish polishing them up for the iPhone. If the iPhone version of Chroma Circuit had been released much earlier in the year, that percentage would have been higher overall, so I’m not ready to say that iPhone development isn’t worth the effort yet. Plus, it’s been a lot of fun learning to optimize for a mobile device and developing with a touch screen, so I’m happy to explore this area more in the coming year just because I enjoy it.

On to 2010!

As I noted above, my earnings as an indie game developer are pretty low in comparison to the salary I used to earn (and what I still earn as a part-time independent contractor). However, I’ve seen steady growth throughout the year from game-related revenue, and I’m expecting that growth to continue into my second year. I don’t know for sure how many months I’ll be able to focus on my own games exclusively in 2010, but it should be at least six again. Hopefully more!

My main goal for this coming year is to explore new sources of revenue. The mobile games space still deserves some of my time, and that will likely include more devices than the iPhone, if they don’t require too large a commitment. Should Adobe offer Flash Player 10 (I’m not interested in Flash Lite) on a device, I’m more likely to play with it. I’m also looking to explore micro-transactions. From what I’ve seen, games that use MochiCoins seem to do pretty well with players (though some portals seem to dislike them), and I definitely want to try adding them (or maybe another service, like GamerSafe or Heyzap) to some totally new games I have simmering in the back of my head. Desktop versions of my existing games are certainly a possibility too. Who knows if I’ll get around to all of that, but I will say that I definitely have a barrel full of ideas for the future of Bowler Hat Games.

22 comments

Monday, January 4th, 2010

Bowler Hat Games Phase Two Begins: Chroma Circuit for iPhone

by Josh Tynjala

Head on over to the iTunes App Store now, and support your favorite indie game developer! Chroma Circuit can now be purchased for the iPhone and iPod Touch. If you’ve played Chroma Circuit before, get ready to experience new touchscreen controls, slick new graphics, and a total of 30 puzzles to solve. That’s 12 more levels than the original web version, plus some remixed levels that better fit the iPhone’s screen.

Alright, with the sales pitch out of the way, let’s get into the nitty-gritty details. First of all, yes, Chroma Circuit is built with Adobe Flash. It’s not Flash Player, though. This is a native app with the ActionScript compiled down to ARM assembly. You can read more about the details in the press release, Adobe Opens iPhone to Flash Developers (which has a quote from me!), and on the Apps for iPhone section of Adobe Labs.

Of course, what everyone’s been waiting for is, what do I think about it? Personally, I absolutely love this technology. I spent a few weeks with Objective-C earlier this year, trying to do a port of Chroma Circuit. I started getting the hang of the language and tools pretty fast, but to be honest, I wasn’t a fan. Too much memory management. Drawing and animation APIs that were a pain. It just wasn’t for me. I kept an interactive prototype of Chroma Circuit sitting around for months without any updates. Then Adobe asked me to help them bring Flash to the iPhone, and I had a more complete prototype within a couple of hours because I could reuse my existing code from the web version with very minor tweaks.

Optimization

Currently, iPhone native apps built with Flash are obviously slower than typical native apps, especially on older phones. The bottleneck, much like in the browser, is the software renderer. I think I’ve seen some speculation that because ActionScript is traditionally an interpreted language that it’s probably very slow when pre-compiled. That’s simply not true, and unless you write crappy code, it won’t be your bottleneck. Adobe has said that they’re using the same software renderer as their browser and desktop runtimes because it keeps things visually consistent. I like that, and I’m excited to see optimization to make it run better on less-powerful devices. Hopefully, that optimization will make its way back to Flash Player itself—much like what’s already happened with Flash Player 10.1—and that it will help push the community to innovate more.

Of course, optimization is not all on Adobe’s side. The fact is, most of us write code that is “good enough” to run on modern desktops. For a mobile device, optimization is more important, and I’m working hard to ensure that future updates to Chroma Circuit run better. Though I haven’t started using the new hardware acceleration feature, cacheAsSurface, I have spent time simplifying some of my graphical effects (which don’t need to be so detailed on such a small screen), ensuring that vectors don’t get redrawn unnecessarily, and making some display list manipulations (like depth changes) more conditional. For the original version, I focused mainly on removing bitmap filters (either completely or replaced by PNGs) and turning static vector art like backgrounds into bitmaps. Both helped quite a bit, and that’s the best I could do with a looming deadline to get it into the App Store in time for Adobe MAX. Now that I have more time to focus on polishing, I can explore and discover new ways to make the game run faster. Again, while I want to see more performance coming from the renderer itself, I certainly am not denying the fact that part of the job is my own.

The Future

What’s coming next? More features and better performance in Chroma Circuit, of course. My other games, Gridshock and Qrossfire, will be getting the iPhone treatment too. Making iPhone games isn’t my sole focus, though. The App Store is not a gold mine, and probably hasn’t been since people started calling it that. Instead, iPhone apps will be just one part of my revenue. Licensing, advertising, iPhone apps, and probably more. Adobe’s Shibuya looked pretty cool. Maybe I’ll make some AIR desktop versions of my games too. Certainly, there are new games simmering in my brain, and I’m sure you’ll see those hitting portals and making their way to iPhones and desktops as well.

That’s the focus of what I call “phase two” of Bowler Hat Games. I want to explore more revenue sources and discover a good mix that will help me reach my financial goals for the business. With the retroactively named “phase one” coming to a close, I hope to share with you a blog post with some charts and analysis showing the breakdown of revenue so far. I haven’t compared all the numbers yet, except to ballpark it all in my head, so I’m pretty excited to get down and dirty with the data.

2 comments

Sunday, October 18th, 2009

Make your company more fun: Start "back channel" conversations

by Josh Tynjala

Put up a whiteboard in your company’s office. Not a whiteboard for meetings, mind you. A whiteboard with a question. Then, drop a bunch of markers next to it and wait for answers. It doesn’t matter what you ask, but try to make it a question that requires more than a “yes” or “no” answer. It could be something fun, or maybe a wild idea that you want validated. Without a doubt, passersby will stop for a moment and start writing. Don’t get it? Here’s an example of a question to ask:

What do we need?

It’s a very straightforward question, but you might be surprised about the answers. You’ll get serious answers about things that slow people down and make it hard for them to do their job. You’ll get inspiring answers about features your products or services may benefit from in the future (maybe even things people might be too scared to suggest in real meetings). You’ll get funny answers about how someone wants “weapons-grade plutonium”. In all cases, you’ll get useful results and engage the people around you. You’ll probably get more than answers, though. The most fascinating phenomenon is that people will start having conversations. Bob will read another Alice’s answer, then comment on it with his own thoughts with a little arrow pointing to the original.

I’ve seen the happen at two companies at which I’ve worked. At one, I was a full-time employee, and at the other, I was a contractor. In both cases, the message board instantly caught on, without explanation. One day it appears, and people instantly get it. In one case, it wasn’t a whiteboard. Nothing was provided for writing an answer. It was just a big thing on the wall with a permanent question (I don’t remember what exactly, but basically, “what are you up to?”). By day two, a clever individual had figured it out, and his or her answer materialized on a post-it. A conversation thread on the board became a cascading line of yellow squares. A couple weeks in, pictures of team members doing fun stuff were taped up there, and it was a great success.

Many business focus engagement so strongly on customers, that a little extra effort to engage employees can be surprising and exciting. A whiteboard or something else that asks a simple question brings a light-hearted atmosphere to the office and it may give you some information about what’s happening behind the scenes that was otherwise hidden. As someone who has experienced this addition to an office environment twice in my career, I highly recommend it for every business.

Start the Discussion

Friday, August 21st, 2009

Bowler Hat Games Introduces Qrossfire

by Josh Tynjala

Two weeks ago, my company Bowler Hat Games released a new game called Qrossfire. Within a short time, Mochi Media featured Qrossfire as a Flash Game Friday winner. Today, the game reached a milestone of one million plays. I attribute Qrossfire’s success to a few factors, including a focus on graphics, better playtesting, and building upon an already successful and familiar gameplay mechanics.

Qrossfire’s Title Screen

With Qrossfire, I spent some extra time creating unique art and graphics. Color, in particular, played a big role in giving Qrossfire the personality it needed and the quality of gameplay I wanted. I tried to pick strong primary colors with heavy saturation, in a balanced set of brightness levels. With both Chroma Circuit and Gridshock, a small number of players complained that some of the colors weren’t different enough, and it made the game a bit harder to play. To compensate in Chroma Circuit, I added a color-blind mode with very high-contrast colors. For Qrossfire, I tried to ensure from the start that the colors I chose would work well together aesthetically and technically. As a fallback, I also added unique shapes to go along with each of the colors.

Qrossfire In-Game

Qrossfire was the first game of mine to use the First Impressions feature on FlashGameLicense. It’s a wonderful option that puts your game in front of a variety of players with many backgrounds and skill levels, and you receive their honest feedback, as if the game were out in the real world. While I’ve heard that many developers put early versions of their games up there, I decided to upload Qrossfire later in development when I was mostly adding finishing touches. Regardless, the participants gave me excellent advice related to sound effects, difficulty, and controls. Between the comments from these helpful souls and very useful suggestions I received some of the potential licensees on FGL, I was able to make Qrossfire more dynamic, interesting, and universally enjoyable. If you sell licenses for your games on FGL, I highly recommend this feature, and I don’t doubt that I will use it again.

From the beginning, I intended to create Qrossfire using an established formula. While I strive to create unique games that stand out from the crowd and go in their own differing directions, even when we’re talking simple puzzle games, there are benefits to me as a game developer to building an old standard that’s tried and true.

More experience. This is only my third game, and a good way to spend more time on graphics, sound, and other non-development areas is to create something that won’t require too much thought from the engineering side of my brain. This choice also lets me spend a bit more time refining the project structure and architecture. What I learn from those possible improvements, I can take with me to my next game and beyond.
Creative exercise. What better way to force myself to be creative than to take an established—and nearly overdone—genre and try to find a fresh way to present it to players? A good balance between new and familiar elements is often the best way to find success.
It’s relaxing. I have plans in the works for an epic sequel to Chroma Circuit with more levels, new game modes, and some very exciting new features—all of which offer me great revenue potential. I’ve also been experimenting and brainstorming for games in genres I haven’t tried yet. Giving my mind a short break from planning those longer-term tasks allows me to restart them later with a fresh perspective and new ideas.

Currently, I’m taking a short break from game development to do some Flex consulting work. I hope that games will be able to pay the bills sooner than later, but I’m still not there yet. Thankfully, I only need to work for about three months to allow myself to work fulltime on games well into 2010. Hopefully, I’ll get started on a new game in early October. In the meantime, I’ll be doing customizations for portals that want site-locked licenses of my existing games, exploring interesting technologies I may be able to use in my games in the future, and enjoying the summer as much as possible.

2 comments

Thursday, July 23rd, 2009

Skipping id in MXML to create private sub-components

by Josh Tynjala

As you probably know, when you create an MXML component in Flex, and you give one of its children an id, that child will become a public property on the class. What if you’d rather make it private because you don’t want code outside the MXML component accessing sub-components? Well, you could do something like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
	creationComplete="application_creationCompleteHandler(event)">

	<mx:Button label="Example" preinitialize="_exampleButton = Button(event.currentTarget)"/>

	<mx:Script><![CDATA[
		import mx.events.FlexEvent;
		import mx.controls.Button;

		[Bindable]
		private var _exampleButton:Button;

		private function application_creationCompleteHandler(event:FlexEvent):void
		{
			trace("_exampleButton:", this._exampleButton);
		}

	]]></mx:Script>
</mx:Application>

In the code above, there’s a private _exampleButton variable that will be used to reference the Button we create in the MXML without an id property. It is Bindable so that we can use its properties in binding elsewhere. Hooking onto the FlexEvent.PREINITIALIZE event, we pass the component reference to the variable using the currentTarget property of the event.

If you have a reason to enforce stronger encapsulation in MXML components, this method could be useful, but it’s probably overkill most of the time. Obviously, this won’t stop someone from using standard display list functions to access the child you “hid” by making it private. I doubt I’ll use this anywhere, but it was a fun exercise, and I thought I’d share.

A Couple Related Links

Feature Request: SDK-219: Access-controlled MXML Properties
Blog Post: Hiding Properties in Flex Components

6 comments

Wednesday, July 22nd, 2009

[Bindable] on a read-only getter is unnecessary and will be ignored.

by Josh Tynjala

Sometimes, when you build a Flex application, you encounter a compiler warning that says, “[Bindable] on a read-only getter is unnecessary and will be ignored.” If you’ve seen that message, and you’re curious what it means, hopefully I can explain it. In short, the compiler is telling you that it can’t actually make that property bindable because it has no way of determining when the property changes.

To understand that better, you should first know a little more about how binding works. Normally, when you make a getter/setter pair bindable, the compiler adds a little extra code for you. Behind the scenes, it dispatches PropertyChangeEvent.PROPERTY_CHANGE to tell the binding system that your property has changed. Basically, it converts your property functions from something like this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable]
public function get example():String
{
    return this._example;
}
public function set example(value:String):void
{
    this._example = value;
}

to this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable("propertyChange")]
public function get example():String
{
    return this._example;
}
public function set example(value:String):void
{
    this._example = value;
    this.dispatchEvent(new PropertyChangeEvent(PropertyChangeEvent.PROPERTY_CHANGE);
}

If you don’t have a setter, there’s nowhere for the compiler to act smart and determine that your property has changed. If you want a getter without a setter to be bindable, you need to specify an event to be fired when the value returned by the getter changes. Your code should look something like this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable("exampleChange")]
public function get example():String
{
    return this._example;
}

Notice the inclusion of the event type in the metadata’s parentheses.

That’s only the first part, though. Next, you need to actually dispatch the exampleChange event from somewhere in your code. For example, let’s say that we change the _example variable when an URLLoader returns a result:

private function urlLoader_completeHandler(event:Event):void
{
    var loader:URLLoader = URLLoader(event.currentTarget);
    loader.removeEventListener(Event.COMPLETE, completeHandler);
    this._example = loader.data.toString();
    this.dispatchEvent(new Event("exampleChange"));
}

Any time you change _example, you need to dispatch the exampleChange event specified in the metadata so that the the binding system knows about what you did. If you set _example in many different places, you might consider making a private or protected setter that sets _example and dispatches that event, but that’s not required.

In summary, the compiler warning goes away when you specify an event type in the metadata. Simply specifying an event type won’t update bindings though, you also have to dispatch that event when the underlying variable changes. When the binding system receives your event, it knows to update any component to which your getter is bound.

One extra thing worth mentioning is that any property with Bindable metadata that has no event specified will dispatch the same generic propertyChange event. This means the binding system will have to work harder than needed because it could receive the same event for many different properties. It’s a good idea to a create custom event for each property to avoid this limitation. You can see in the Flex framework source code that Adobe has separate events for most, if not all, bindable properties they create.

6 comments

Wednesday, July 15th, 2009

Sometimes, fl.core.UIComponent redraws too often

by Josh Tynjala

Recently, as I was working on a Flash component (not a Flex component, mind you), I found myself wondering why the component would redraw for supposedly no reason. It had obviously drawn itself to display the current state after a property change, but sometimes it would throw in one extra redraw a bit later. If you’re unfamiliar with the way the “fl” components work, they use a system of invalidation where property changes will queue up a drawing cycle for later (typically before the next frame is drawn by Flash Player’s renderer). When the extra redraw slipped in there, it seemed that something wasn’t getting cleaned up properly during the validation cycle.

When you create an “fl” component that has children that are also “fl” components, you’re required to call a function named drawNow() on the sub-components inside the parent’s draw() function. You want to do this because many users will find it aesthetically undesirable to see those sub-components update one frame later rather than immediately. In fact, the architecture actually forces you to call drawNow() because it refuses to queue another redraw while in the “call later phase”. Of course, there are ways to force “fl” sub-components to invalidate during that call later phase if you don’t mind patching the source yourself, but that’s a different story.

Call later, or else!

That’s the background for how the architecture works. Here’s the problem I discovered. When you set a property of a sub-component from outside its parent, that sub-component will invalidate and callLater() will get it ready for a redraw. If, for some reason, the parent redraws before its sub-component, the sub-component will draw when drawNow() is called, but the redraw it independently queued up earlier won’t be removed from the queue!

The only time that the draw() function gets removed from the queue is when the callLaterDispatcher() receives the stage’s render event. Instead, UIComponent should account for the possibility that a certain functions that will be “called later” may not need to be called again if they get called early. Here’s a patch to fl.core.UIComponent that will do just that for component drawing:

protected function validate():void
{
	invalidHash = {};

	//remove draw() from the "call later" queue
	delete this.callLaterMethods[draw];
}

I simply added one line at the end of the function validate() This function gets called at the end of draw(). The default version only cleans the invalidation hash, which tracks changes to minimize the number of component parts that need to redraw. My addition also ensures that it only redraws once. If the component has validated, then there’s nothing invalid to require another draw.

It’s worth noting that an extra redraw isn’t the end of the world. For most components, it won’t cause any noticeable problems, but for some, it may impact performance. Things like the layout containers in Yahoo! Astra are a bit more CPU-intensive than most “fl” components because they need to determine ideal dimensions, the best positioning of components, and whether scrollbars are needed and that involves some nasty looping. They have a few flags to indicate whether certain changes affect the layout at all, but still, that’s not always perfect and drawing the component again for no good reason isn’t useful.

By the way, if you ever want to monkey patch a component in a specific Flash or Flex project, it’s easy.

Copy the original source file into a new file. Make sure the package structure is the same as the original.
Make any changes that are needed.
Add the folder for the top-level package of the new component to your compiler’s “source path”. Make sure your patched source is higher in the list than the original version so that the compiler knows that it is more important. Typically, if the patched version is in the project’s own directory, it will be given more importance.

Enjoy!

Start the Discussion

Thursday, June 25th, 2009

New from Bowler Hat Games: Gridshock

by Josh Tynjala

Another creation from my indie game venture, Bowler Hat Games, has been released into the wild. It goes by the name Gridshock, and I see it as a bit of a combination between a couple classic puzzle games, Tetris and Collapse!. It’s a lot less of a thinker than my previous game, Chroma Circuit, but I wanted to aim at a more casual market this time. That said, I think everyone can enjoy Gridshock.

Screenshot of Gridshock

Development for Gridshock went a lot faster than with Chroma Circuit. I completed Chroma Circuit in a bit over a month, while it took me only three weeks to finish Gridshock. I think this happened for a few reasons.

Chroma Circuit was the very first game I built in Flash, and I spent a lot of time finding the right way to structure my projects, balance development vs. design time, and really had too strong a focus on various “administrative” things. I was able to jump into Gridshock pretty quickly because I had become very comfortable with that stuff by the end of Chroma Circuit’s development, and they moved more into the background.
I did most of my visual design work for Gridshock in Flash CS4. Chroma Circuit had some very specific geometric requirements that needed a lot of programmatic drawing. I tried the visual drawing approach at first, but the in-game objects simply wouldn’t fit together properly with the tiny variations made by creating the art by hand, so I had to scrap a couple early attempts and do it all the mathematical way. For Gridshock, a vast majority of the art was finished in only a couple of days, and I focused much more on programming game mechanics than programming graphics.
Content creation for Gridshock was much easier. Chroma Circuit had levels that needed to be designed, and I didn’t put together my Flex-based level editor until the very end (for use if I make a followup). Gridshock has a fixed playing area that doesn’t change as the game progresses. I had to focus on making the same basic play area more replayable rather than using variety like I had in the previous game.

Early prototypes for Gridshock varied quite a bit from the final product. When the initial idea for the game popped into my head, I imagined activating lights on the board from four different directions. Unfortunately, the pace of the game ended up being pretty slow, and clearing the board was absolutely trivial. There was no good way to add new rows to speed it up, so I had to rework my idea a bit. The second variation simplified gameplay to activating lights from the left and the right sides of the board, with lights settling in the middle rather than on the right edge, as in the final version. I found it was too difficult to move back and forth to both sides of the grid. When I simplified the board one last time, I also added the timer on the right that pushes a new row on the bottom. This quickly proved to be the most fun and playable version of the game.

I made another modification with my final prototype worth mentioning. It allowed players to click anywhere on the row to activate a light. In the first builds, the smaller lights on the left side that indicate color were buttons instead. Expanding the clickable area to the entire row made for fewer player mistakes, and a bit of a faster pace. Interestingly enough, this change may actually make it easier for a bi-directional version of Gridshock to be possible again, since the mouse movement won’t be as fatiguing as when I tried it the first time. I’ll certainly consider it if I make a sequel. I have other interesting ideas for board layout that may be more interesting, though.

Please go take a look at Gridshock. It’s a fun little puzzle game that’ll help you waste a few minutes of your morning or afternoon. If you haven’t played any of my games yet, I encourage you to check out Chroma Circuit too. That one’s a bit more cerebral and deliberate. I also recently finished development of my third game, called Qrossfire. It’s another casual puzzle game, and I’m pretty proud of the way it turned out. The graphics, in particular, really pop. Qrossfire will be out once I find a sponsor. If you’re a developer with an account over on FlashGameLicense, go take a look and give it a rating (thanks!). This week, I’m deep in brainstorming stage for the game I want to build next. I’m planning to branch out from the puzzle game genre, now that I’ve gotten more comfortable after finishing a few games, and I’m pretty excited. Stay tuned for more from Bowler Hat Games!

Start the Discussion

Tuesday, May 26th, 2009

Pages: Prev 1 2 3 4 5 6 7 8 9 10 ...18 19 20 Next