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!

Much discussion ensued in the Flash and Flex world today as Adobe announced to the community that they’re rebranding Flex Builder as Flash Builder. It’s a good change, in my opinion. Though I consider myself a Flex developer at least half the time, I think I’ve actually worked on more pure AS3 projects in Flex Builder than Flex projects. It’s clearly not a Flex-only development environment, and the new name is far more accurate and widens the audience, in my opinion. It may cause some initial confusion (as all rebranding does), but I think that any problems will clear up quickly.

I’ve noticed a few people wonder out loud if explicitly declaring that Flex is a part of the Flash brand in the product name will turn off developers who are considering Flex. We all know that a certain subset of the developer community has a lasting grudge against Flash due to its occasional misuse on the web, so this almost seems possible. However, I suggest thinking critically about that concern for a moment. Don’t you think it’s rather obvious that Flex runs in Flash Player? Is it really conceivable that a developer would never realize that Flex is really Flash-based with even the smallest amount of research? If someone is so anti-Flash that simply seeing the name of the development tool would turn them away, I would expect them to have the same reaction after a quick visit to their favorite search engine or Wikipedia to learn a little more about Flex.

Also, can we stop with the irrational fear that Flash Builder will replace the Flash authoring tool? Do you really think Adobe would decide to start ignoring the massive number of Flash content creators who draw things by hand, work with animation on the timeline, and understand symbols in the library much better than code in classes? Flash Builder is a code-centric development tool that advanced developers find more comfortable and productive. It would need years and years of development time to implement all the features needed to replace the Flash authoring tool. Not to mention the massive amounts of training Adobe would have to commit to in order to move developers and designers from one to the other. These two tools, Flash CS and Flash Builder, have many of their own unique use-cases, but they can also co-exist for the same user. I create art for my games and applications in Flash CS, while I write all my code in the current version of Flex Builder. They’re separate tools, though, and both must exist for Adobe to have any chance of making their target audiences that don’t overlap happy. You need only look at the incredible differences between the layouts of each tool to see that. For some of us, that means we need to purchase both, which may be a little expensive. Personally, I’d say that each falls under “one tool that does one thing, but does it well”, so they’re worth the price.

Changing the name of the development environment you use shouldn’t mean that you must change your job title, the experience you list on your resume (one word only, if you happen to list the tools you know), or what you write in job descriptions when you want to hire a developer. A Senior Flex Developer is still a Senior Flex Developer, regardless of whether he or she uses Flash Builder, FDT, FlashDevelop, or a simple text editor like TextMate with a command line compiler from the Flex SDK. A Flash Developer is still a Flash Developer in the exact same way. If you build Flex applications, then market your technical knowledge by only talking about Flex, Flex, Flex(!), if you feel that’s important. You don’t need to tell your clients what IDE you use, if you’re worried that the word “Flash” will cause them undue stress. Personally, I think you’re probably causing yourself too much stress by wondering how the name change will affect others.

As I’ve probably made clear, I don’t believe that the name change from Flex Builder to Flash Builder will be bad for either brand. What’s strange to me is that I’ve seen the strongest pushback coming from the Flex developers in the community. What’s up with that, guys? I consider myself one of you, but sometimes I don’t understand you. The name Flex will become much clearer because it will always be a Rich Internet Application framework that runs on Flash Player. No more IDE that’s called Flex (but does more than Flex), no more expensive server requirements. Those parts of the old Flex brand are surviving separately on their own merits now, as they should, and the framework can now be Flex without interference. The ubiquitous Flash Platform will solidify a bit more with another “Flash” branded product, and maybe the Flash name will even a little more respect from those developers who think Flash is all about animation and banner ads. I doubt that Flex will lose any respect, though. It gained ground with developers outside the Flash community because it’s a great open source framework for building RIAs, not because it somehow separated itself from Flash. Sometimes, good libraries and frameworks can change the minds of developers by being just that, good. Look at how JavaScript went from being a web toy to becoming a serious language in the last several years. I think Flex will continue to gain mindshare in a similar way, and I think it can only benefit the Flash Platform as a whole.

Have you ever looked at the returned value of the function flash.utils.getQualifiedClassName() and wondered why it includes :: between the package and the class name? For example, if you pass in a MouseEvent instance, you’ll get the string value "flash.events::MouseEvent". The first time I tried it, I expected to receive "flash.events.MouseEvent" with a . because that’s how you reference a packaged class in an import statement. I always thought the difference was a little strange, but I just shrugged and went about my business. Today, though, my mind must have been feeling a little extra clever than ususal because it suddenly dawned on me: you use :: as an operator in ActionScript 3 to access a namespace.

With one simple test, it became unquestionably clear that packages in ActionScript 3 are really an abstraction built on top of namespaces. Try running the following code using the Flex SDK or the Flash authoring tool:

namespace flash_events = "flash.events";
trace( flash_events::MouseEvent ); //output: [class MouseEvent]

No import needed!

I imagine this has ECMAScript 4 roots. In general, many of the OOP features of AS3, like class and package syntax, are considered syntactic sugar. How can AS3 developers benefit from this knowledge? I have no idea, but it’s one of those discoveries that whispers, “someday, you may need me”.

Sometimes, you want to know the datatype of an object at runtime. The most common thing to do in ActionScript 3 is use the is keyword to see if an object is an instance of a specific class. For example, you use exampleObject is Sprite to see if something is a Sprite (or any subclass of Sprite). However, there are times when you want to use the actual class in your code to create a new instance, or to do something a little more arcane. There are a couple simple ways to access the datatype of an object and place it in a variable.

Method 1: Combine a couple flash.utils functions

The first way to get an object’s class at runtime takes requires calls to a couple useful functions that live in the flash.utils package:

import flash.utils.getQualifiedClassName;
import flash.utils.getDefinitionByName;

var example:Sprite = new Sprite();
var exampleName:String = getQualifiedClassName( example );
var exampleType:Class = getDefinitionByName( exampleName ) as Class;
trace( exampleType == Sprite ); //output: true

Start by calling the function flash.utils.getQualifiedClassName(), and pass in the object. It will return a string that includes the full class name, including the package. For example, passing in a Sprite object will return the String value "flash.display::Sprite". Next, call the function flash.utils.getDefinitionByName(), and pass in the String value that you just received. It will return a reference to the object’s class. An equality check is included in the code above to demonstrate that exampleType is actually the Sprite class.

Are you curious about that :: part of the fully-qualified class name? Shouldn’t it be . instead? Check out my post Packages are actually namespaces in ActionScript 3 to learn more.

Mainly, I’ve included this first method of extracting a class from an instance because the two utility functions used in the example above are quite useful in other contexts. However, the second method is much simpler, if a little more obscure.

Method 2: The constructor property

Every object in ActionScript 3 has a property named constructor. According to the documentation, it is a reference to the datatype used to instantiate the object. In other words, every object can tell you the Class (or Function, since AS3 still supports ECMAScript function prototypes) used to create it with one simple property lookup. How simple!

var example:Sprite = new Sprite();
var exampleType:Class = Object( example ).constructor;
trace( exampleType == Sprite); //output: true

What’s interesting, and not immediately obvious (unless you read the documentation thoroughly), is that if you try to access the constructor property in the strict mode (which is on by default in the AS3 compiler), you’ll get a compiler error. However, the documentation notes that dynamic objects don’t cause this error. We can use that fact to create an easy workaround because everything is an Object, and Object happens to be a dynamic class. As you can see in the code above, a simple cast makes the error go away.

Personally, I prefer the second method because it takes only a simple property lookup, and it requires no calls to functions with long names. Again, though, those functions can be quite useful in other contexts, so it’s worth making note of them.