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.

Screenshot of Chroma Circuit for iPhone

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.

5 comments
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.

Screenshot of Qrossfire's Title Screen
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.

Screenshot of Qrossfire Gameplay
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.

1 comment
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

3 comments
Wednesday, July 22nd, 2009
Pages: Prev 1 2 3 4 5 6 7 8 ...46 47 Next